On 17/10/2013 13:27, Quoth Ben Fritz:
> This way, after you commit the changes you received to /vendor, you will
> then use an svn merge command to pull those changes over into wherever
> you are maintaining your customizations. In this way, you always have a
> pristine copy of the actual vendor code, and you always have the ability
> to merge in vendor updates using SVN's merge machinery so that you don't
> lose your local changes.
Right. But my point is that the current implementation of "vendorbranch
here" does not actually help with this scenario.
You can't use it on the /vendor branch itself because it doesn't track
moves/renames, so the merge will go astray.
You can't use it on your /trunk version because that will discard the
local changes.
It's only of use specifically in the case when there are no
moves/renames (or at least that your local edits do not include any of
the files that have been moved/renamed). So you might get lucky
sometimes, but you can't rely on that because you don't know what the
external vendor is going to do between releases.
There's also a possible workflow issue -- when using svn_load_dirs for
example I never needed a working copy that had the /vendor location
checked out already, because the script checks it out as needed itself.
As this is a drag command it requires that you do that manually
beforehand. (Having said that, I was never a fan of the auto-commits
done by svn_load_dirs, so this approach might be better.)
Again, I'm not saying that the feature itself is bad, or that it doesn't
have its uses. I'm just saying that given the complete lack of
documentation in TSVN itself (unless I've just missed it?) bar the
one-liner in the release notes, when people find it they're going to
think of that section of the SVN book, and it does something different
from that. So it shouldn't have the same name.
From what I can tell, the closest approximation of the workflow
required to do somewhat-change-preserving vendor branching is this:
1. Check out /vendor/libname somewhere.
2. SVN Copy /vendor/libname/oldver to /vendor/libname/newver.
3. Right-click-drag the folder containing the newver code to the
/vendor/libname/newver folder in the WC and "SVN vendorbranch here" [I'd
still prefer "re-import" or similar]
4. Commit.
5. Go back to your normal WC and do a two-trees merge from
/vendor/libname/oldver to /vendor/libname/newver.
6. Fix up any conflicts.
7. Manually re-add any customisations you made to renamed/moved files,
since you just silently lost those.
8. Test and commit.
(I'm not a fan of step 7, but it seems unavoidable without rename tracking.)
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3066470
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-17 03:00:22 CEST