Scott Palmer wrote:
> Yes... perhaps I just need to warm up to the idea. The fact that a
> copy is made in the repository only to exist for the duration of the
> build process seems sloppy to me. Like I'm cluttering the repository
> with noise that doesn't belong there. Even though it does effectively
> solve the problem.
Revision numbers are cheap (we've got 2^16 of them if memory serves).
And since you can delete the tag when you are done with it, you won't
even "see" it unless you look at the log. They are not clutter; they
are history. And unlike CVS, additional copies do not bloat the
repository in the slightest, since Subversion effectively does a copy on
write; unless and until you change something in the tag, it exists only
as a snapshot of the subtree.
> I disagree that the revision number is 'internal' though. It's reported
> to the user all over the place and it is used all the time for merging
But that's right now; when Subversion grows mergepoint tracking (like
SVK has already), the number of times you *need* to know the revision
number is going to significantly decrease.
> and other operations. The examples in the subversion book use it at
> least as often as it uses tags, when appropriate. The global revision
> number is a very public property of the repository and it's use seems to
> be encouraged rather than discouraged, depending on the situation of
> course.
The conceptual distinction I'm trying to make is that the revision
number is related to the state of the repository itself (i.e. it is
global), and it doesn't have a special meaning to the individual
subprojects. It is related to the number of people on the users list
who want to know why they cannot have $Revision$ in Subversion work the
same as $Revision$ in CVS did, at least at a project level. Tags can
contain information specific to the subproject, but since the revision
number is global it signifies nothing special about anything
I think the Subversion documentation is largely documenting the way that
the Subversion project /itself/ operates, and the examples are biased in
that respect. If you have a collection of loosely coupled subprojects
with varying updates rates, you are going to use Subversion in a very
different fashion from Subversion's own basically single project repository.
I wonder if it is possible to perform multiple copies in a single
transaction (by using the -F option to 'svn cp'), which would neatly
deal with your concern with race conditions between tagging and
building. Even if it isn't, tagging is very fast, so if your build
script performed all of the tags first, it is very unlikely you would
have a disjoint set of files when you eventually checked them out.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 22:29:52 2005