Duncan Murdoch <murdoch@stats.uwo.ca> writes:
> 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.
I've always considered this to be a form of "tagging" (CVS does it
too), and yes, storage will be shared where possible.
However...
> 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.
...you may still prefer to use Duncan's method, which has the
advantages he described.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 15 17:12:14 2006