Hopefully this'll get sorted out when SVN does proper merge tracking,
but in the meantime it's a bit counter-intuitive and error-prone.
Ok, here's the issue. I'm using SVN 1.3.2, and the following sequence
causes problems.
1. Create a vendor branch for the version of third-party code you're
currently using.
2. Create another branch (using svn_load_dirs.pl) for the latest
version, which you want to upgrade to. This must contain both
additional folders and additional files within existing folders.
3. In a clean working copy (which is based on the first version of
vendor code, but contains some customisations that have already been
committed), perform a merge from the first branch to the second branch.
Now in theory you've got the upgraded code while preserving any
customisations.
4. Revert all changes.
For files that existed before the merge, everything is fine, you're now
back at what you had before. Files that the merge created, however, are
left behind, as unversioned files. I guess I can understand this, since
it has no idea whether the "local modifications" were from the merge or
through getting written by a user.
5. Immediately redo the merge operation (without deleting the
unversioned files first).
The merge succeeds, and everything seems happy now. The files that used
to be unversioned are now listed as "add with history", as expected.
6. Try to commit.
The commit fails on every one of those previously-unversioned files,
citing that the file does not exist, and specifying a path to a
transaction file on the server.
I'm a little unclear as to exactly what I did after this, but I know it
involved repeated "update" and "cleanup" cycles, since the updates
tended to fail with "not a working copy" errors, on the folders that
were created as part of the merge. (It also magically deleted the .svn
folders inside them, which had existed prior to the update.)
In the end, of course, I managed to do the merge by reverting all the
way back and deleting the unversioned files before trying the merge
again. But it wasn't a particularly user-friendly experience, and the
error message wasn't very helpful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 12 03:19:46 2006