switch to subversion?

switch to subversion?

[Per Bothner]

Some projects are switching from CVS to Subversion (I thought
Apache was one of them, but I can't find confirmation).  Apart
from the various ways in which CVS is "better" for version
control, another claimed advantage is security.  For example
people can check in changes into a SVN repository without having
a local account on the server.

I don't know much about the internals and security implications
of either, and I'm certainly not volunteering for anything, but
curious what people think about the idea.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: switch to subversion?

[Jason Molenda]

On Fri, Dec 19, 2003 at 11:38:01AM -0800, Per Bothner wrote:

> I don't know much about the internals and security implications
> of either, and I'm certainly not volunteering for anything, but
> curious what people think about the idea.


I think anyone you talk to will be greatly interested in general
(it'd be like asking "Who here likes kittens") but IMHO it's more
trouble than you'd want for a big project at this point.  I don't
know if any of the system maintainers really has the time to learn
enough about svn and keep up to date on it to support an installation,
and there will certainly be a need for support when it is first
brought up.  Any group switching to svn will have a big cost of
all the developers trying to re-learn their revision control system
- even though I know the svn folks are trying to keep it similar
to a cvs style RCS.


J

Re: switch to subversion?

[Zack Weinberg]

Jason Molenda <jason-swarelist@molenda.com> writes:

> On Fri, Dec 19, 2003 at 11:38:01AM -0800, Per Bothner wrote:
>
>> I don't know much about the internals and security implications
>> of either, and I'm certainly not volunteering for anything, but
>> curious what people think about the idea.
>
> I think anyone you talk to will be greatly interested in general
> (it'd be like asking "Who here likes kittens") but IMHO it's more
> trouble than you'd want for a big project at this point. 

General agreement with this, also I don't think subversion scales to a
project the size of gcc (much less /cvs/src!) yet, and I am currently
thinking that monotone (http://www.venge.net/monotone/) will suit our
purposes better.  It isn't ready yet either, though.

zw

Re: switch to subversion?

[Benjamin Kosnik]

>General agreement with this, also I don't think subversion scales to a
>project the size of gcc (much less /cvs/src!) yet, and I am currently
>thinking that monotone (http://www.venge.net/monotone/) will suit our
>purposes better.  It isn't ready yet either, though.

I would love to see gcc start testing monotone. I concurr: it's looking
very sharp. (It's also been tested with the gcc repository, which gives
me hope.)

-benjamin

Re: switch to subversion?

[Ian Lance Taylor]

Benjamin Kosnik <bkoz@redhat.com> writes:

> >General agreement with this, also I don't think subversion scales to a
> >project the size of gcc (much less /cvs/src!) yet, and I am currently
> >thinking that monotone (http://www.venge.net/monotone/) will suit our
> >purposes better.  It isn't ready yet either, though.
> 
> I would love to see gcc start testing monotone. I concurr: it's looking
> very sharp. (It's also been tested with the gcc repository, which gives
> me hope.)

I would like to see a free version control system which implements
change-sets.  (My understanding is that Bitkeeper implements them.)

In my mind, a change-set is essentially a large patch file (it would
typically implement a particular feature).  Applying a change set
essentially means running patch.  A version control system which
supports change-sets makes it easy to create and to apply change-sets.
It should do version tracking of change-sets, so that a single working
tree can be the combination of several change-sets, and it should be
possible to update a working tree to a new copy of a particular
change-set.

The application of change-sets is trickier than a three-way merge,
because there is no known ancestor revision, so conflicts are hard to
handle.  But the concept is powerful.

I wouldn't be very enthusiastic about switching to a new version
control system if it didn't support change-sets.  While I'm ready to
believe that subversion and monotone are a better CVS, in my opinion
CVS itself still works well enough for what it does.


Ian

Re: switch to subversion?

[Joseph S. Myers]

On Fri, 19 Dec 2003, Zack Weinberg wrote:

> General agreement with this, also I don't think subversion scales to a
> project the size of gcc (much less /cvs/src!) yet, and I am currently
> thinking that monotone (http://www.venge.net/monotone/) will suit our
> purposes better.  It isn't ready yet either, though.

Are you maintaining your feature wishlist for version control for GCC
(<http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html> plus anything else that
came up in that discussion or subsequently), so that candidate systems can
be compared against it again?

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: switch to subversion?

[Zack Weinberg]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> On Fri, 19 Dec 2003, Zack Weinberg wrote:
>
>> General agreement with this, also I don't think subversion scales to a
>> project the size of gcc (much less /cvs/src!) yet, and I am currently
>> thinking that monotone (http://www.venge.net/monotone/) will suit our
>> purposes better.  It isn't ready yet either, though.
>
> Are you maintaining your feature wishlist for version control for GCC
> (<http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html> plus anything else that
> came up in that discussion or subsequently), so that candidate systems can
> be compared against it again?

No, sorry, I haven't time.

zw

Re: switch to subversion?

[Jim Blandy]

Jason Molenda <jason-swarelist@molenda.com> writes:
> On Fri, Dec 19, 2003 at 11:38:01AM -0800, Per Bothner wrote:
> 
> > I don't know much about the internals and security implications
> > of either, and I'm certainly not volunteering for anything, but
> > curious what people think about the idea.
> 
> 
> I think anyone you talk to will be greatly interested in general
> (it'd be like asking "Who here likes kittens") but IMHO it's more
> trouble than you'd want for a big project at this point.  I don't
> know if any of the system maintainers really has the time to learn
> enough about svn and keep up to date on it to support an installation,
> and there will certainly be a need for support when it is first
> brought up.  Any group switching to svn will have a big cost of
> all the developers trying to re-learn their revision control system
> - even though I know the svn folks are trying to keep it similar
> to a cvs style RCS.

It may be worth mentioning that Subversion is not tied to HTTP,
WebDAV, and Apache.  There is an alternative protocol which tunnels
over ssh just like CVS does, and has a server which is much less
trouble to build, install, and maintain.

Subversion's main funding comes from a group very connected with
Apache, so despite the fact that the alternative protocol is really
much better as the standard access method, it's politically
impractical to highlight it too much.

Re: switch to subversion?

[Jim Blandy]

"Zack Weinberg" <zack@codesourcery.com> writes:
> General agreement with this, also I don't think subversion scales to a
> project the size of gcc (much less /cvs/src!) yet, and I am currently
> thinking that monotone (http://www.venge.net/monotone/) will suit our
> purposes better.  It isn't ready yet either, though.

Not to imply that performance is the only relevant question, but why
do you say this?  Subversion was designed to scale much better than
CVS does.

- There should be less interference between committers and readers.
- Identifying changed portions of the tree for update should be much
  faster than is possible in CVS.
- Branching is a constant-time operation in Subversion, which makes
  branches more useful.

Re: switch to subversion?

[Jim Blandy]

Ian Lance Taylor <ian@wasabisystems.com> writes:
> I wouldn't be very enthusiastic about switching to a new version
> control system if it didn't support change-sets.  While I'm ready to
> believe that subversion and monotone are a better CVS, in my opinion
> CVS itself still works well enough for what it does.

I agree entirely that changesets are the ne plus ultra of version
control.  While there is a plan to support changesets in future
versions of Subversion, they certainly aren't even on the schedule
right now.

Re: switch to subversion?

[Jim Blandy]

Jason Molenda <jason-swarelist@molenda.com> writes:
> Any group switching to svn will have a big cost of all the
> developers trying to re-learn their revision control system - even
> though I know the svn folks are trying to keep it similar to a cvs
> style RCS.

Although I'm not the best person to express an opinion on this, I
don't actually think the learning curve would be very steep at all.
The work cycle is the same as CVS's:

    $ svn checkout http://svn.red-bean.com/repos/minor/jimb/wip
    ...
    A  wip/doc
    A  wip/doc/synchronization
    A  wip/doc/design
    A  wip/doc/locks
    A  wip/doc/leases
    ...
    Checked out revision 145.
    $ cd wip
    $ vi doc/locks
    [ make some changes ]
    $ svn commit
    Waiting for Emacs... [ enter my log message] Done
    Sending        doc/locks
    Transmitting file data .
    Committed revision 146.
    $ svn update
    U  doc/design
    Updated to revision 147.
    $

Re: switch to subversion?

[Zack Weinberg]

Jim Blandy <jimb@redhat.com> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>> General agreement with this, also I don't think subversion scales to a
>> project the size of gcc (much less /cvs/src!) yet, and I am currently
>> thinking that monotone (http://www.venge.net/monotone/) will suit our
>> purposes better.  It isn't ready yet either, though.
>
> Not to imply that performance is the only relevant question, but why
> do you say this?  Subversion was designed to scale much better than
> CVS does.

As an empirical matter, last I heard subversion was orders of
magnitude slower than CVS for all operations, on repositories
of comparable size.

I don't know if this is still true, nor do I know *why* it is/was
true - you're right that the design ought to scale much better than CVS.

zw

Re: switch to subversion?

[Zack Weinberg]

Jim Blandy <jimb@redhat.com> writes:

> I agree entirely that changesets are the ne plus ultra of version
> control.  While there is a plan to support changesets in future
> versions of Subversion, they certainly aren't even on the schedule
> right now.

Whereas, monotone has had them since day one, and this is one of the
primary reasons why I think it suits GCC better.

zw

Re: switch to subversion?

[Andrew Cagney]

"aegis".

> I would like to see a free version control system which implements
> change-sets.  (My understanding is that Bitkeeper implements them.)
> 
> In my mind, a change-set is essentially a large patch file (it would
> typically implement a particular feature).  Applying a change set
> essentially means running patch.  A version control system which
> supports change-sets makes it easy to create and to apply change-sets.
> It should do version tracking of change-sets, so that a single working
> tree can be the combination of several change-sets, and it should be
> possible to update a working tree to a new copy of a particular
> change-set.
> 
> The application of change-sets is trickier than a three-way merge,
> because there is no known ancestor revision, so conflicts are hard to
> handle.  But the concept is powerful.
> 
> I wouldn't be very enthusiastic about switching to a new version
> control system if it didn't support change-sets.  While I'm ready to
> believe that subversion and monotone are a better CVS, in my opinion
> CVS itself still works well enough for what it does.