[Techtalk] collaboration... - subversion

[Cynthia Kiser]

I goofed and sent my question directly to Meredydd instead of the list
so am now forwarding her great response to the rest of the list - with
a couple of follow up questions. 

----- Forwarded message from Meredydd <meredydd at everybuddy.com> -----

On Friday 30 May 2003 06:04, Cynthia Kiser wrote:
> Quoting Meredydd <meredydd at everybuddy.com>:
> > Oh oh oh - while we're at it, I'll stick my oar in in favour of
> > subversion(.tigris.org) which is simply the coolest repository system
> > I've seen.
>
> I am a CVS fan who is curious about subversion - especially the part
> on their site that said its purpose was to fix the things that were
> wrong with CVS. Would you care to enthuse more specifically about
> subversion?
This is a quote from my posting to the Everybuddy list, justifying my choice:

--- begin quote ---

> I should have subv up by tonight....could I have clarification as to why
> we are using it please?
Generally, because it kicks CVS around the block in terms of flexibility
(Rename a file? Why would anyone want to do that?), robustness (Can *you*
remember which characters cause interesting effects when used in CVS
filenames, because RCS uses it as an internal separator? And what about
binary files?), and general feature density (adding a directory
recursively to CVS falls foul of the above, or at least has failed for me
with no obvious reason before).

It also makes commits properly atomic, and decently versioned. Under CVS,
if I change three source files and then commit, I actually make three
separate transactions - for example, taking foo.c from 1.1 to 1.2, bar.c
from 1.19 to 1.20, and baz.c from 1.5 to 1.6. If one of these changes
fails, the one before it stays (because it's already been completed), and
the one after it doesn't happen, leading to possible inconsistency in the
contents of the repository. The only thing these three events share is a
commit log (copied) and a timestamp. If I want to roll back the
repository, I have to crawl through the timestamps and roll them all back
individually.

With Subversion, by contrast, when I commit, I take the entire repository
from, say, version 22 to version 23. If it fails, it fails, and the repos
isn't touched. If it succeeds, the whole thing changes. If I want to roll
back to version 18, I can, with one command.

In other words, it just makes my life one hell of a lot easier :)
We've been running on subversion since EbQt started really getting
anywhere, and although we have encountered some issues with it, at no
point ever have I banged my head on the table to the extent I used to with
CVS. I call that progress :)

--- end quote ---

Oh yeah, and its branching and merging is also very cool - branches are just 
separate directories within the repository tree - which also has the 
incidental benefit that their creation and deletion is versioned along with 
the rest of the repository. Merging is powerful but a little complicated -
you need to remember the changesets you're merging in, which generally means 
recording the revision at which you forked the branch. I just keep a little 
file called REVS with them all in. Making this easier is a TODO, but it's 
very powerful and certainly usable as is. The issues I refer to above are 
mostly to do with using it over SSH - we've had no problems at all using it 
over WebDAV with Apache 2.

I've missed out a whole load of cool stuff it can do - for a more in-depth 
discussion, check out "Subversion: The Definitive Guide" at 
http://svnbook.red-bean.com/book.html

Meredydd


----- End forwarded message -----

I will check out the book. In the mean time, do you recall what issues
you had using ssh? I have private repositories so always use cvs over
ssh - usually using exchanged keys or ssh-agent to get around typing a
password every time I want to see what I have changed.

I am also a little confused about your merge comment. Why do you have
to keep a list of where you forked the branch? In the line above you
said 
  "branches are just separate directories within the repository tree -
  which also has the incidental benefit that their creation and
  deletion is versioned along with the rest of the repository"
So I would have expected that you could just look up where the branch
was started. If subversion kept track of where you did incremental
merges, that would ROCK. But if it doesn't, that just means that you
are at the same place as with CVS - using tags or your REVS list to
keep track of when you merged what. 

-- 
Cynthia N. Kiser
cnk at ugcs.caltech.edu