Scott Palmer wrote:
> The fact that HEAD can change at any time is exactly why I want to
> capture it.
But that is exactly what making a copy does; it is a snap shot of that
portion of the repository at that point in time, which is completely
equivalent to the rev number at the same point in time.
> Doesn't work. Copies don't track changes to the originals. I have
> multiple projects that are part of a single build. At best I could use
> svn:externals, but sadly checking out is not an atomic operation with
> svn:externals because each external reference is considered a separate
> checkout. That puts me back where I started.
Copies are not intended to track changes. Every single time you need to
make a build, make a copy first, which freezes the state of the
repository at the point of the copy. If you don't need to keep these
copies around after you are done, delete them. It is a single node in
the repository and takes up no physical storage (apart from the storage
for the node itself).
> This suffers from my original problem as well. In this case I would
> want to automatically create the tag from the trunk of several projects
> - at the same revision, to avoid potential conflicts that might arise if
> some of the projects that depend on each other are being changed while
> the build script is making the tags.
As long as all of the projects are in the same repository, you could
make a copy of the tree above all of the projects, then build from that
location instead. This is a fast, fully atomic copy (once you start the
transaction, any changes that come in until you finish it are ignored).
In every way it is completely equivalent to getting the HEAD revision,
except that you then don't need to keep track of that revision number,
since simply referring to the new copy path already encodes which
revision you are pulling from.
> If I have a change made that effects two related projects I would want
> to commit the changes in both projects as a single atomic commit (which
> isn't always easy with Subversions UI, but one problem at a time). The
> revision number represents these atomic changes so I would like to make
> sure that builds are done from only one revision of my repository. That
> means deciding on some single revision to use for the builds, or
> capturing HEAD at some point of time.
The revision number is an internal bookkeeping value - an artifact of
the repository structure. It /can/ be used to denote a point in time
for the repository as a whole, but it is much better to create a tag
which can contain meta information significant to the developer (like a
standard tag with the date/time embedded in the name).
I'm not saying that your method is wrong, merely that it is not using
the Subversion tools most effectively.
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 17:45:00 2005