fedora version control
Thomas Arendsen Hein
thomas at intevation.de
Fri Jul 7 12:22:01 UTC 2006
* Neal Becker <ndbecker2 at gmail.com> [20060704 01:09]:
> Anyone want to comment?
>
> http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/
For easy reference I quoted the arguments here:
| Mercurial Pros
|
| - Atomic
Yes.
| - Mercurial uses Unix account based access control.
Yes, and there are even more possibilities using hooks and
extensions.
| - SSH or Apache authentication and transports (write access through
| http see below)
| - Repo replication and private branches allows great flexibility in
| testing things on the side that would be unsuitable for mainline.
| When those side things are "ready", propogating changes back is
| easy and low overhead.
| - Mercurial is python, matching our state religion.
3x Yes.
| - It appears possible to have representations of one thing be a copy
| of another directory or repository on the same mercurial server
| that maintains history and everything. This could be useful.
I don't understand this.
| - Mercurial developers are willing to add missing functionality if
| that makes sense.
Yes, and if does only make sense to some and not to others, an
extension probably can handle that.
| Mercurial Cons
|
| - Mercurial can do only per-repository granularity access control.
| Repositories would need to be an incredibly huge number,
| per-package * per-branch, which would be incredibly ugly. (Note by
| mercurial dev (BO'S): This is not true; there's an acl extension
| that lets you do access control down to the file or directory
| level within a single repository.)
Besides the acl extension you can use hooks to have your very own
access system, e.g. only allow pushes to certain directories if they
are gpg signed, pass a test suite or whatever.
| - Options for hiding branches: currently you must put it on another
| server. (Note by mercurial dev (BO'S): Or you can choose not to
| publish a branch. Adding a blacklist feature, such that you
| publish by default but hide specific branches, would take perhaps
| five lines of code :-)
Alternatively use something like contrib/hg-ssh for limited ssh
access and your webserver's htaccess rules for http/https.
| - Currently not possible to checkout only an entire repository, not
| just a sub-directory. Depending on the structure of our repository
| this be quite bad. Future Mercurial plan to make partial checkout
| possible. (Note by mercurial dev (BO'S): If this is important to
| you guys, we can implement it sooner, rather than later. We tend
| to develop features according to both developer and user interest;
| we very much like keeping our users happy, and acquiring new users
| who can also be happy :-)
You can already do this in an unconvenient way, e.g.:
hg revert -r Revision Directory1 Directory2 File3 Directory4
hg debugsetparents Revision
The only thing that is missing is tracking the list of what you've
checked out and what not for further updates, so you don't have to
specify the list all the time.
Doing 'hg commit' or 'hg diff' already ignores missing files.
| - Does mercurial push (write access) really only work via ssh? See
| http://www.selenic.com/pipermail/mercurial/2006-April/007542.html
| (Note by mercurial dev (BO'S): We allow push over https and http
| now, too.)
Yes, you just have to use a current development version for this
feature.
Thomas
--
Email: thomas at intevation.de
http://intevation.de/~thomas/
More information about the Mercurial
mailing list