On 3/15/2006 7:56 AM, Nick Thompson wrote:
> If I checkout a revision from trunk and then copy the new WC to the
> repo URL at tags/foo, is the copy just as cheap, in repo disk space
> terms, as a directr URL to URL copy (normal tagging)? Obviously, it
> will take longer, at least due to the check out, but that doesn't
> matter to me.
> The reason I ask, pushes the question further forward a bit: I want to
> checkout a trunk revision, do some release work on it (add a change
> note and build some released items, ...) and then but the whole lot
> back to a release tag. I don't want to do this though if the majority
> unchanged files where not stored cheaply.
> If its not cheap, I guess I will be forced to do a URL to URL copy to
> tags and then check that out, modify it and check back in - which is
> not strictly tagging.
I don't know the answer to your question, but I think this objection
isn't really valid: if the version you check in isn't identical to some
version on the trunk or a branch, then it's not strictly tagging. What
it looks like you're doing is what you describe below.
Maybe I should use a release branch instead and
> tag that when I'm done, but it seems like process overhead that I
> don't need and will clutter the repo with useless branches.
> Any other ideas?
What we do is make a stable branch from the trunk when we're getting
close to a release; we commit only bug fixes to the branch. At some
point the release manager makes the last minute changes you describe,
commits it to the branch, and then tags it.
This means anything in the tags subdirectory really is a snapshot of
something somewhere else, and the log tells you where it was copied
from. It also allows us to continue to make bug fixes on the branch, so
people who want the features of the release but without the bugs know
where to go.
I think this is a fairly standard flow, and it works well.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 15 14:38:49 2006