What if you created a baseline branch and use svn copy to create a
baseline and merge to re-baseline. Then, you'd have your link. I'm not
sure if this follows the entire process you're aiming for, tho.
Michael
________________________________
From: Scott Palmer [mailto:scott.palmer@2connected.org]
Sent: Monday, December 19, 2005 12:49 PM
To: Granse, Erik ((STP))
Cc: users@subversion.tigris.org
Subject: Re: Labeling techniques
On 19-Dec-05, at 12:18 PM, Granse, Erik ((STP)) wrote:
We're trying to do something a little more file-centric than
Subversion likes and I'm looking for thoughts on our problem.
We have a need to identify particular revisions of particular
files as 'baselined' (e.g., completed peer review, etc.). We need to be
able to identify all files that have been baselined (and ideally, all
files which have not been). A file may be re-baselined if changed. We've
thought through a few different strategies and haven't found one that
works well.
...
- The Subversion tagging mechanism has limitations for dealing
with files. If we tag a file into tags/baselined, we then have to browse
the tags directory to learn which files have been baselined rather than
being able to keep that information with the file in the trunk.
You could possibly use 'svn switch' on the files that are baselined.
Then they would show up as switched when you did 'svn status'.
But that does carry over to the WC on other checkouts. You would have
to do something different for that.
Also, we won't be able to re-baseline a file without deleting it
and recopying it or else maintaining a large directory tree to
accommodate multiple baseline revisions. The former method means that we
can't do a log on a single file to see baseline history and the latter
method would just be a mess.
Having a 'baseline' branch seems to make sense. Perhaps you could
combine that with some scripts that would 'svn switch' only the files
that were also available in the baseline branch?
Scott
Received on Mon Dec 19 20:57:19 2005