when to use svn copy

[JamieEchlin <ja...@credit-suisse.com>]

What are the acceptable cases for using svn cp? Superficially, it can be used
for creating branches or tags, and indirectly as part of a move/rename
operation, and restoring a deleted file/dir, but are they any other
justified usages? 

What we see a lot of, and are considering blocking going forward, is people
svn cp'ing files between branches. For instance, you are on trunk, and want
a file that has been added in branch 1.1... instead of merging you just svn
cp the file or subdir you are want. This is a kind of targeted cherry
picking, but without mergeinfo. Of course, you get a tree conflict when you
come to merge correctly.

So my question is, is the above an acceptable usage? Presumably this seems
much easier to users than doing a merge.

cheers, jamie
-- 
View this message in context: http://old.nabble.com/when-to-use-svn-copy-tp30748502p30748502.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: when to use svn copy

[Jonathan Paul <jo...@wandisco.com>]

Hi Jamie,

as you have already pointed out you lose the mergeinfo - I would say that
this is not acceptable from an auditing point of view, and it also causes
headaches later for the person who has to merge stuff from the branch back
to another branch.

Jon

RE: when to use svn copy

["Echlin, Jamie" <ja...@credit-suisse.com>]

> And it can happen naturally during refactoring.
> For example, you might want to split a file into two distinct 
> files, preserving their common history.

Good point. Thanks.
jamie
 

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 

Re: when to use svn copy

[Stefan Sperling <st...@elego.de>]

On Tue, Jan 25, 2011 at 11:36:02AM -0000, Echlin, Jamie wrote:
> > But doing copy operations within a branch root (i.e. they 
> > don't cross branch boundaries) is fine.
> 
> Is a copy, as opposed to a rename/move really fine? I'm not sure why
> people would want two files in the same branch to share a common
> history. In this case, what I believe happens is that people svn copy an
> existing class (or whatever) as the basis of a new class, when a
> filesystem copy and Add might be more appropriate. Anyway, I think this
> process is indicative of other problems in the development lifecycle.

It's not necessarily a problem.
Deriving things from one another, preserving history, is a valid use case.
This is a pretty good thing to do actually since it preserves e.g. accuracy
of svn blame output.

And it can happen naturally during refactoring.
For example, you might want to split a file into two distinct files,
preserving their common history.

But also, a rename is a copy+delete. So when we talk about copies around
here that usually includes renames :)

Stefan

RE: when to use svn copy

["Echlin, Jamie" <ja...@credit-suisse.com>]

Thanks Stefan, excellent answer. 

> It was basically assumed that users would easily grok the UI 
> because a "copy" is a simple concept that's also known to 
> people who haven't used version control before.
> However, when you also do advanced stuff like merging you 
> need to understand how to use the copy operation appropriately.

Yes... I see that some of the UIs are trying to disambiguate branches
from copies, by instance restricting choices for the source of a merge
to those copies that are antecedents or have mergeinfo or something (the
collabnet eclipse plugin). This seems like a good direction. (Something
for Tortoise maybe?)

> Users need to be aware of branches and use merge to transfer 
> changes between them. So the new files should be merged from 
> the other branch, not copied.
> And ideally all merges such happen at branch roots (just like 
> in any other version control system).

Yes... Our "SubCop" refuses to allow merges that didn't happen at the
branch root. 

> But doing copy operations within a branch root (i.e. they 
> don't cross branch boundaries) is fine.

Is a copy, as opposed to a rename/move really fine? I'm not sure why
people would want two files in the same branch to share a common
history. In this case, what I believe happens is that people svn copy an
existing class (or whatever) as the basis of a new class, when a
filesystem copy and Add might be more appropriate. Anyway, I think this
process is indicative of other problems in the development lifecycle.

> the version control needs of the next decade would be (recall 
> that the designers of Subversion were coming from CVS). Today 
> we know what most people need. And because Subversion was 
> made flexible it's entirely possible to use Subversion in a 
> way that's very pleasent *if* you know what not to do.
> You've run into one of these cases...

Yes. It makes sense. I read that "subversion always assumes the user
knows what they're doing". Unfortunately that doesn't hold true in the
real world (at least the corporate world).

Cheers, jamie

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 

Re: when to use svn copy

[Stefan Sperling <st...@elego.de>]

On Tue, Jan 25, 2011 at 01:32:30AM -0800, JamieEchlin wrote:
> 
> What are the acceptable cases for using svn cp? Superficially, it can be used
> for creating branches or tags, and indirectly as part of a move/rename
> operation, and restoring a deleted file/dir, but are they any other
> justified usages? 
> 
> What we see a lot of, and are considering blocking going forward, is people
> svn cp'ing files between branches. For instance, you are on trunk, and want
> a file that has been added in branch 1.1... instead of merging you just svn
> cp the file or subdir you are want. This is a kind of targeted cherry
> picking, but without mergeinfo. Of course, you get a tree conflict when you
> come to merge correctly.
> 
> So my question is, is the above an acceptable usage? Presumably this seems
> much easier to users than doing a merge.

Subversion conflates the concepts of branch/tag creation and copying
internally as well as at the UI level. Some people consider the latter
to have been a design mistake. There is no real reason why the UI should
expose the implementation detail that a branch is just a copy.
It was basically assumed that users would easily grok the UI because a
"copy" is a simple concept that's also known to people who haven't used
version control before.
However, when you also do advanced stuff like merging you need to
understand how to use the copy operation appropriately.

Users need to be aware of branches and use merge to transfer changes between
them. So the new files should be merged from the other branch, not copied.
And ideally all merges such happen at branch roots (just like in any other
version control system).
But doing copy operations within a branch root (i.e. they don't cross
branch boundaries) is fine.

Now you might want to know why Subversion is so flexible that is allows
users to do stupid things like this in the first place.
One reason why there are few restrictions on what users can do is that
back in 2000 many didn't know or understand what the version control
needs of the next decade would be (recall that the designers of Subversion
were coming from CVS). Today we know what most people need. And because
Subversion was made flexible it's entirely possible to use Subversion
in a way that's very pleasent *if* you know what not to do.
You've run into one of these cases...

Stefan