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