Hi Stefan and Roy, sorry for the late response. This sunny sunday took me for a trip into the mountains. :-) See the inlines below.
> The normal state of an ASF project is that all people who contribute
> code on a regular basis have write access - if they want it.
I would not advise to commit to the ASF SVN repository directly. Changes
put into SVN are carved into stone and immutable FOREVER. Mercurial
allows a more flexible way for working on things. Just read this mail to
the end to get there. :-)
I know this may be a bit much information and it could feel like "uoh,
what the heck does this guy mean - do I have to learn all these
things?", but it's not really complicated and the learning curve should
be exponential. So I get straight to the next topic:
> But once the people who would be working "in connected mode" in a
> distributed VCS have been doing it for long enough that the existing
> committers have gained enough trust the whole thing won't be necessary
> any longer. The people who stick around long enough will get write
> access to svn sooner or later.
The main goal is to keep the SVN trunk stable and safe in every
revision. Since the SVN repository history is immutable, this means that
only revised and "good" patches are put there.
Therefore I would like to propose a different workflow that works just
great when working in a team. Think of "log4net", "log4net-crew" and
"log4net-developer" as repositories. The "log4net-developer" repository
will actually exist for every developer and maybe even multiple times if
one developer works on more than one issue. The flow of data is basically:
log4net <--> log4net-crew --> log4net-developer
^ |
| v
apply patch <-- discuss patch
What does that mean for us? Each developer has a local clone
(log4net-developer) of the repository log4net-crew and works on that
clone to fix an issue. The changesets produced there can then be
discussed by other developers and once - let's say - more than half of
the developers agree on how things are done, the patch is applied to
log4net-crew and subsequently put back into the log4net SVN @ apache.
You may ask yourself how we can discuss on a changeset if the others
don't know about it? Mercurial offers some very convenient ways to share
information between developers. One is to publish the information in a
repository so that others can pull that information into their local
clone (that's how mercurial works after all) or the other way would be
to mail a patch to this list so that others can import it and comment on it.
One could export a patch and then send it manually to this list:
$ hg export rev > patch.diff
Or he can use the patchbomb extension that does exactly this in a oneliner:
$ hg email rev
Now other developers can import the patch manually:
$ hg import patch.diff
or use again an extension called Mbox that does the reverse operation of
Patchbomb in a oneliner:
$ hg mimport
Finally the other developer revises the changesets and provides feedback
on the mailing list. Once every on agrees it is really easy to put the
changes to the log4net-crew repository:
$ hg push log4net-crew
And from the crew repository, whoever has write privileges on the svn,
can do:
$ hg pull log4net-crew
$ hg push log4net
Obviously I stripped some information on how one has to set up things,
but rest assured that I'm going to provide that information if you ask
for it.
Last but not least I want to mention some useful links. The most
interesting things should be written down here (without the chapter
about Fabric):
http://www.satchmoproject.com/blog/2010/feb/27/satchmo-workflow/
and more general information on mercurial can be found here:
http://mercurial.selenic.com/wiki/QuickStart
But that wiki contains also more information. For example the
installation and usage of extensions that this kind of workflow need are
well documented there:
http://mercurial.selenic.com/wiki/RebaseExtension
http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/MboxExtension
http://mercurial.selenic.com/wiki/PatchbombExtension
And there's a more than useful windows client called TortoiseHG
(http://tortoisehg.bitbucket.org/) that eases the commandline hacking
with a nice userinterface (even mq, patchbomb and other things).
Feel free to ask if you feel you need to!
> The normal process is that a committer resolves the JIRA issue once the
> code is in svn. Sometimes the user who opened the issue will close it
> after the fix has been verified but this is truely optional.
Yes. Right now we can only comment on issues, which is obviously not
enough to be productive. We should contact some people @ JIRA so that at
least one of us gets write privileges to the repository and
administrative privileges to the bugtracker ASAP.
Best regards,
D.
signature.asc
Description: OpenPGP digital signature
