[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: when to use svn copy

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 25 Jan 2011 12:12:51 +0100

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

Received on 2011-01-25 12:13:34 CET

This is an archived mail posted to the Subversion Users mailing list.