On Mar 28, 2005, at 9:31 AM, John Peacock wrote:
> Scott Palmer wrote:
>> I would use it to ask at the beginning of by build procedure what the
>> HEAD revision is and then checkout or export that specific version of
>> all the projects. Also, for some things I do an export, so
>> svnversion can't work on the WC anyway. I was just looking for a
>> simple way to do an automated build for a specific rev. I don't want
>> to have a person check the head revision number and type it in.
>
> I'm trying to understand why you are not using Subversion's cheap
> copies to perform this magic for you, rather than trying to capture
> some ephemeral value like HEAD (which can change at any time).
The fact that HEAD can change at any time is exactly why I want to
capture it.
> A much more efficient way to do what it seems like you want to do is:
>
> $ svn cp svn://repo/path/to/project svn://repo/path/to/tags/unique
> $ svn co svn://repo/path/to/tags/unique ./local/path/project
> or
> $ svn export svn://repo/path/to/tags/unique ./export/path/project
>
> If you are managing multiple sub-projects, make a copy of each into a
> common top level directory in the repository, then export/checkout
> them all at once.
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.
> Except for very small projects, it is probably wrong to build off of
> HEAD; you should always tag then build off the tag. If your builds
> are intended to be one-off (say by an automated build process), create
> a ./build directory in the repository at the same level as ./trunk,
> ./branches, and ./tags, then once the build has been verified as OK,
> delete the copy (you can always get back to that if you need to using
> the history). That way, your ./build directory normally contains only
> failed builds (very useful for manual followup).
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.
> Is there some reason this method won't work much better for you than
> trying to capture the value of HEAD at some point of time?
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.
I also prefer to tag after verification rather than before, but that's
just because it's what we've been doing all along. Tagging after the
fact is easy so long as I know the revision (or revisions) used for the
build. While we are in the earlier stages of development we aren't
really concerned with tagging. The tags wouldn't be relevant long
enough for us to bother making them.
I'm not saying that changing some of our build/development practices
wouldn't help. But changing the process can be significantly
disruptive and therefore isn't always simple.
We're getting off-topic, starting a discussion that is more appropriate
for the users list I think. But hopefully the point about having a
nice clean simple way to get the HEAD revision has been made? Though
there are alternatives, I don't see that this is going against "the
Subversion way". I'm trying to play to some of subversions strengths -
the atomic commits in particular. (Just wish they were more atomic
with svn:externals, but that's another subject... I've suggested
svn:internals to cover that case.)
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 17:05:20 2005