[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Branching: not getting it

From: Henderson, Michael D <michael.d.henderson_at_lmco.com>
Date: 2004-04-27 03:45:10 CEST

I'm having to rethink our processes a little to line them up with Subversion. The current process is pretty manual. Developers work on a development box, write the code, test and check in to VSS when they're ready. The tech team receives an email from the developer, with the VSS path and version number. They migrate the change to the test box. After it's tested, the change is flagged as ready to go live. The tech team has a spreadsheet with the VSS path to the file and the version number. At go live, they copy files one by one. It works, but it's painful, and I think that Subversion can improve, but I need to be sure that I'm understanding branches.

I've attached an outline of what I think the process should be like with Subversion and would appreciate feedback.

The tech team creates two branches, one for QT testing and the other for holding tested and approved changes.

 $ svn copy svn://zinc/batch/trunk svn://zinc/batch/branches/rc1.test -m "Release Candidate 1 QT sandbox"

 $ svn copy svn://zinc/batch/trunk svn://zinc/batch/branches/rc1.accept -m "Release Candidate 1 production path"

Question: Is it possible to svn copy svn://zinc/batch/trunk svn://zinc/batch/branches/rc1/test instead?

The developers can work on the trunk of the repository to their heart's content. The developer commits a change and send a note to the tech team with the file paths and the revision number. As changes come in from the developers, the tech team copies the changes into the branch.

 $ svn copy --revision {developer's rev} svn://zinc/batch/trunk/{developer's path} svn://zinc/batch/branches/rc1.test/{developer's path}

On the test box, the tech team does a export from the QT branch to sync the test box.

 $ svn export svn://zinc/batch/branches/rc1.test/{developer's path} batch/{developer's path} --force

Question: This seems like overkill to me, but I haven't been able to export a single file. When I try, I get the following error (this is in 1.0.2).

 subversion/libsvn_fs/dag.c:427: (apr_err=160016)
 svn: Attempted to create entry in non-directory parent

The documentation describes the command as exporting a clean directory tree, but it takes a URL so it seemed fair to try to specify a file. As usual, I could be confused. Happens a lot.

After the test team blesses the change, the tech team does another copy on the file, this time into the rc1.accepted branch.

 $ svn copy --revision {developer's rev} svn://zinc/batch/trunk/{developer's path} svn://zinc/batch/branches/rc1.test/{developer's path}

Question: Does it matter if it is from rc1.test, would copies of copies of copies produce problems in the future?

If the test team rejects the change, the tech team undoes that copy. I'm assuming that an svn log will pick up the previous revision number to roll back to. If not, it's back to the spreadsheet.

 $ svn copy --revision {previous rev} svn://zinc/batch/trunk/{developer's path} svn://zinc/batch/branches/rc1.test/{developer's path}

Question: The svn revert won't work since the prior copy is URL to URL, so it's automatically commited, right?

At go live, rc1.accepted is exported to the production box, and all of the rc1 branches are deleted.

 $ svn delete svn://zinc/batch/branches/rc1.test -m "Removing obsolete branch"

 $ svn delete svn://zinc/batch/branches/rc1.accept -m "Removing obsolete branch"

Question: I think that the way that we're using branches is similar to how tags are described in the book, so would this make more sense to create as tags/ instead of branches/?

Aside from the export, I think that this uses Subversion the way that it was designed and that I've got the commands right. Again, I'd appreciate any feedback, especially if I'm making this harder than I have to.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 27 03:45:42 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.