On Mar 28, 2005, at 10:41 AM, John Peacock wrote:
> 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.
The key word here is "portion" I want a snapshot of several different
portions as they existed at the same instant That's very easy to do if
I pick a revision number to make the snapshot from.
> 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.
Same issue, make a copy from which revision? I see you address this
below...
> 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.
Now this comes close to a viable solution. Though the copies would
have all sorts of unrelated projects and I don't like the idea of
implying they are part of the build by including them in the 'build'
copy. I also want builds to be independent of version control. The
Subversion repository should not need to be modified for me to do a
build. I want to make tags or copies when I choose, not because I'm
forced to just to get a build done. That such copies might only be
transient by-products of the build process is all the more reason that
they shouldn't be there.
> 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).
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. I guess it can be argued that it *does* belong in
the repository as a record of what was built... but since there is no
way to undo it if I decide to abort the build etc., it still doesn't
seem right.
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 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.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 21:31:18 2005