-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hrvoje Niksic wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>
>>> Make my src changes, create a "changeset"... And then I'm lost...
>> Alright, so you can make your changes, and issue an "hg diff", and
>> you've basically got what you used to do with svn.
>
> That is not quite true, because with svn you could also do "svn
> commit" to upload your changes on the global repository seen by
> everyone. It is my understanding that with the "distributed" VC's,
> the moral equivalent of svn commit is only to be done by the
> maintainer, by pulling ("cherry-picking") the patches of various
> contributors.
Untrue. That is simply the model some (notably, Linus and friends)
choose to use.
As with the Subversion set up, active developers with permissions may
"push" to the central repositories; I actually mentioned this during the
initial announcement, but am using SSH key-based authentication to
accomplish this, and so require people's SSH keys in order to give them
push access. So far, the only one who has given their SSH key is
actually Ralf Wildenues, whose key I requested so he could easily push
any necessary changes related to the Automake stuff. So: send your key,
and you'll have push access!
Note that I still prefer to review non-trivial changes, just as I did in
Subversion; but just as in Subversion, I decided against ACLs and
allowed everyone write permission to trunk, though I preferred to merge
there myself, I want all core devs to have write permission to the
public repos, so they can push quick fixes.
> It is most likely the case that I simply didn't (yet) "get" the DVCS
> way of doing things.
It takes a little bit of getting used to, but you'll find that many
things directly translate from using a non-distributed SCM. The biggest
differences that arise (for me so far) tend to be related to the fact
that history is not a linear series of events, where each log entry is
the child of another; it is instead a directed acyclical graph, where
the history can branch off and re-merge later, leaving all history
intact. Subversion and friends, of course, support branching and
merging, but the history wouldn't merge along with the changes, and
you'd typically get the branch merge as one big "slurp" of the total
changes. Tools like svnmerge helped address this (by merging each change
individually, which could be problematic in some circumstances).
For my part, I found using Mercurial very easy to learn, and it is
purposely designed to use an interface very similar to Subversion. It
just takes a little getting used to, like any conversion to a new,
heavily-relied-upon development tool.
- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHE3177M8hyUobTrERCMpZAJ9MUGXaYa2r+SBmFEujdrnwvjNITQCfevJN
qh2Jicj1A9Iv8Po3E8EUGTA=
=gkeP
-----END PGP SIGNATURE-----
