On Mon, 2002-07-15 at 17:06, Isak Johnsson wrote:
> Quoting the contents of the Subversion FAQ:
>
> > 17. Why does the entire repository share the same revision number? I
> > want each of my projects to have their own revision numbers.
> If I've got it right, then I'm supposed to put different branches and
> major versions in different directories in the same repository. If that
> means that they'll have the same revision number, I can't count on the
> revision number to know when it's time to rebuild a branch? Nor can I
> correlate bug reports by their revision numbers even if the source is
> identical.
Rebuilding dependant on the revision is *far* easier than on CVS.
Although a caveat - I don't really understand CVS.
Yes, the repository has a single revision number, which is utterly
fantastic.
Yes, you can rebuild individual directories based on revision number
sanely, I do it all the time:
svn info gives me (for the subversion trunk dir):
Path: .
Url: http://svn.collab.net/repos/svn/trunk
Revision: 2546
Node Kind: directory
Schedule: normal
Last Changed Author: david
Last Changed Rev: 2546
Last Changed Date: Tue, 16 Jul 2002 05:23:22 +0100
Properties Last Updated: Tue, 16 Jul 2002 08:36:50 +0100
Note the "Last Changed Rev:". For automatic rebuilds, that's probably
what you want.
So it's relatively easy to say:
LOCALREV=`svn info --recursive | grep '^Last Changed Rev:' | sed 's/^.*
//' | sort -n | tail -n 1`
(I'm uncertain whether I need the recursive check here - I know at worst
case it'll give me the same version number as a simple svn info, so I'll
do it until someone tells me not to.)
And use that as your local rebuild test. (I check to see if I've built
an RPM with that already, for instance, although this could be done
better.)
Bug report correlation is much the same, although my "feel" is that
seeking out which file was the root cause of the bug is probably vastly
easier with SVN than with CVS, since you actually know what files were
changed between which builds easily, as well as knowing what was
actually in each build.
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 11:37:45 2002