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

Creating a branch without specifying an absolute URL.

From: <andy.glew_at_amd.com>
Date: 2004-04-01 21:07:11 CEST

Anyone familiar with CVS - or, at least, with teaching
beginners to use CVS - knows that you need to tell people
to forget about making branches with cvs rtag,
and instead make branches in your current working
dir with cvs tag -b.

More specifically, the way I recommend to make a branch
in CVS, when you are in a working directory
that has changes that you have decided
you do not want to check in to the trunk, is

cvs tag -b BranchTag?
cvs update -r BranchTag?

and now you can check in your changes to the new branch

The similar way in Subversion seems to be

svn copy . http://svnrepo/branch/Absolute-New-Branch
svn switch http://svnrepo/branch/Absolute-New-Branch

This sucks, because it requires the URL
of the new branch to be specified absolutely.

Yes, you can do something like
    svn copy . `svn info | grep URL | script-to-munge-url`/New-Branch
to allow a relative branch.

I'll do that, but I was wondering if there is a better usage
model. Since branch paths are entirely by convention,
whatever script-to-munge-url-to-branch-base
I come up with will not work on all repositories.

svn copy . relative-branch
   might work, but Subversion gives me the error
"unsupported feature... cannot copy path into it's
own child".

Which makes sense in Subversion's model, but still leaves
the rather annoying feature that branch URLs have to
be specified absolutely.

---
(I come from the "task branch" school, checking in early and
often on a new branch.  I may make a dozen such task
branches in a day.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 1 21:08:05 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.