svn merges vs. 'cvs2svn --cvs-revnums' properties

The following issue just came up on a large CVS repository which was
converted to svn. We're also trying out version 1.5.0, because we
really like the new merge capabilities.

The --cvs-revnums option will:
    Record CVS revision numbers as file properties in the Subversion
    repository. (Note that unless it is removed explicitly, the
    last CVS revision number will remain associated with the file
    even after the file is changed within Subversion.)

Thus, if you have a project with multiple branches, then the same
filename may have different values for cvs2svn:cvs-rev in different
branches. If we then go to merge changes in from one branch to a
different branch, we get into a bunch of merge-conflicts.

I think we're just going to fix our repository to remove all of those
cvs2svn:cvs-rev properties, because that property isn't really as
useful as we initially thought it might be. But it seems to me that
this may be an issue which will hit a number of other people as they
start using 1.5 and the merge features.

It seems to me that this might be an example of a "general" problem
and might be worth a "general solution" at the subversion level. I'll
admit I have no idea what that should be, or even if there is any good
way to address it.

I guess the problem is that 'cvs2svn' is putting a *revision*-specific
value as a *file* property, and there just isn't any good (painless)
solution once that has been done across an entire repository. Maybe
the most that can be done is to put a bigger warning around the
--cvs-revnums (both in the 'man' page, and in the command itself).

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org