[Techtalk] collaboration... - subversion

[Meredydd]

On Friday 30 May 2003 15:12, Cynthia Kiser wrote:
> 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.
Cool, glad you liked the response. Fraid the "her" isn't quite accurate, 
though - I'm male, last time I checked at any rate. That said, I'm told that 
can be fixed these days :-)


> 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.
Hmm. Well, I was using an earlier version, and so am not sure whether it's 
fixed, but I had occasional database corruption. It could always be fixed 
with an "svn recover" (think that's the command, can't remember now - it's 
been a while), just a bit of a pain sometimes. On the plus side, setting up 
an SSH-based SVN system is one hell of a lot easier than WebDAV. You just 
create the repos with "svnadmin" on the server, tell the client to use SSH, 
and use a URL beginning svn:// - it's that easy.

> I am also a little confused about your merge comment. Why do you have
> to keep a list of where you forked the branch?
OK, quick and incomplete rundown:

A subversion repository, however big, consists of a huge directory structure 
(albeit one with medium to large amounts of metadata, such as commit notes 
and arbitrary user data attached to any one file or directory). It tracks and 
controls changes to this directory tree as commits are made, but it is 
essentially still this tree. A branch is simply made with an "svn copy" - to 
take an example from my personal experience, setting up my development repos:

I have a tree containing all the Everybuddy components. I wanted to maintain 
three branches of the tree, so that users could track anything from what I 
was hacking on to the stable-ish alpha builds. I did it by placing a copy of 
all my code in the "trunk/" directory. I then performed the command
"svn copy trunk bleeding" to make a lazy copy of the "trunk" directory, called 
"bleeding" ("lazy" in that the server didn't in fact duplicate the data - it 
just noted down that the contents of the directory contained the same data it 
already had). I then repeated the process for "alpha", and committed.

I then had three copies of exactly the same tree, at a certain revision number 
for the repository (call it 10). I then carried on merrily hacking away at 
"trunk". When I wanted to promote my latest set of changes into "bleeding", I 
performed a merge. Given that the copy was made at version 10, I would have 
done: "svn merge -r10:HEAD http://subv.everybuddy.com:888/svn/trunk ." in the 
bleeding/ directory. This command means "apply the changes between versions 
10 and HEAD (latest) of <that URL> to this directory" - as if I had made a 
patch of the changes I'd made, and then applied that patch to the current 
directory. I then commit, and note down that my revision is now 15. Next time 
I promote from trunk to bleeding, I would use "-r15:HEAD" - otherwise, it 
would be like attempting to apply an already-applied patch. Normally, 
subversion is quite smart about this, and notifies you that some of these 
changes have already been applied, but it's best to be safe and avoid relying 
on the safety-net.

What would be ideal would be for subversion to somehow remember the last 
version of another branch a certain branch is synced to (if that makes 
sense). That way, I could just "svn merge <url>" and have it merge all the 
relevant changes. Unfortunately, this has not yet been implemented.

Meredydd