Vladimir Prus wrote:
David Abrahams wrote:
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way? What made you think Beman thought that? Are you not going to answer that?
Unless SVN 1.5 is compatible with svnmerge in any way, then the fact that merge tracking is implemented in SVN 1.5 is rather irrelevant to our using or not using of svnmerge. It can as well be said that Perforce, svk, bzr, git, monotone and mercurial have merge tracking -- that's true, but has no bearing to anything. So the only way to interpret SVN 1.5 remark is to assume that it's some argument in favour of svnmerge.
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW. I'm sure you're right. I don't think anyone thought differently, though. Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5. What is your argument against using svnmerge.py before svn 1.5 is available?
The fact that interfaces of svnmerge.py and svn 1.5 will be different, and any instructions written for svnmerge.py will have to be rewritten, and that developers will be confused when we switch, and unless you force everybody to merge all branches right before switch to 1.5, you'll have branches that have both svnmerge.py and svn 1.5 mergeinfo, and it's doubtfull that either tool will be able to handle that.
We could probably enforce this in the pre-commit hook though, catching any use of the old svnmerge.py properties. And it's pretty likely that there will be a migration path: http://subversion.tigris.org/merge-tracking/func-spec.html#migration-and-int... "TODO: Merge meta data from svnmerge.py. Dan Berlin has written Python code to perform this migration; it needs to be made available in the tools/server-side/ area of the distribution ." -- Daniel Wallin Boost Consulting www.boost-consulting.com