Is copy from wc to repo a "cheap" copy?

[Nick Thompson <ni...@agere.com>]

Hi,

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. 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?

Thanks,
-- 
> Nick Thompson

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Is copy from wc to repo a "cheap" copy?

[kf...@collab.net]

Duncan Murdoch <mu...@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

Re: Is copy from wc to repo a "cheap" copy?

[Duncan Murdoch <mu...@stats.uwo.ca>]

On 3/15/2006 7:56 AM, Nick Thompson wrote:
> Hi,
> 
> 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.

Duncan Murdoch

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org