SCM choices for the server (was Re: kdrive and xgl DDXes)
Felix Kühling
fxkuehl at gmx.de
Wed Jun 22 18:02:08 PDT 2005
Am Mittwoch, den 22.06.2005, 14:51 -0400 schrieb Adam Jackson:
> On Wednesday 22 June 2005 13:13, Keith Packard wrote:
> > On Wed, 2005-06-22 at 13:05 -0400, Adam Jackson wrote:
> > > Fair enough. Are we planning to move kdrive and xgl into the same CVS
> > > module as the other DDXes at some point?
> >
> > Dunno. It's kinda nice to have a place to play that doesn't affect any
> > distributions...
> >
> > Would be nicer if we had a 'real' SCM.
>
> I definitely agree. And before we go any further down that line of
> discussion, let's formally declare what seems to be the consensus:
>
> kdrive and xgl will not be in 7.0.
>
> So there. We may want to tag and tarball that tree at some point for a
> semi-stable release, but that's a parallel effort.
>
> So the next question is how we want server development to look in the future,
> and tied up in that decision is our choice of SCM. I think if we stay with
> CVS for the release server, then we definitely need a separate tree for
> experimental, which means the joy of syncing. I suspect no one wants to use
> CVS more than necessary though.
>
> I don't know enough about the choices to make any authoritative decision, and
> I certainly don't expect any consensus out of this thread. But I would like
> to hear some ideas.
>
> - ajax
I've been using Subversion for my own stuff for a while, and I'm quite
happy with it. The basic concept and user interface is similar to CVS,
so there is hardly any learning curve. Some nice features of subversion
include
* atomic commits (transaction semantics)
* time of many operations depends on the change size, not the
repository size (for example svn update).
* needs less network bandwidth than CVS by sending diffs in both
directions
* some operations can be performed off-line (svn diff against last
checked-out revision, svn revert, svn status)
* directory structure is under version control, moving/renaming
files and directories while preserving the history is trivially
easy
* supports symbolic links
* revision numbers are consistent across the entire repository (in
CVS revision numbers are per-file)
* branches are just directories in the repository. Branching a
tree makes a "cheap" copy that shares a common history with the
original tree
* Subversion users are managed independently from system users.
Thus no ssh access is required for accessing the repository.
With the Apache module you can get fine-grained access control
per-directory instead of per-repository (never tried that
myself, though). In theory that allows for example limited
access to certain branches in the repository (for example
release branches) or giving new commiters access to a specific
branch only
For more info see http://subversion.tigris.org.
I have no intention of starting a discussion or flame war here. Just
tossing in some facts for those who have to make a decision in the end.
Regards,
Felix
--
| Felix Kühling <fxkuehl at gmx.de> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
More information about the xorg-modular
mailing list