On Wed, Oct 16, 2013 at 7:59 PM, Gavin Lambert <tsvn_at_mirality.co.nz> wrote:
> 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.
>
In my experience moved/renamed files are rare. But then I generally
work with C code on embedded systems. Maybe things like Java are
different.
>
> 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.
How hard is it, really, to check out a copy of the vendor branch on
the relatively rare occasion you need to update it? Personally I
EXPECT if I'm making changes to something, I'll need a working copy
for it. Not needing a working copy should be an extremely rare
exception.
> 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.)
>
So how about this instead?
1. Check out /vendor/libname
2. Right-click-drag the folder containing the newer code over the top
of /vendor/libname
3. check for modifications
4. do a "repair move" for any files that did get renamed (will this
work? maybe there is a manual "undo add" and such needed first)
5. commit
6. go back to normal WC and do a plain old normal merge from /vendor/libname
7. fix up any conflicts
8. test and commit
If step (4) doesn't work, then maybe the "repair move" feature needs a
little improvement for use cases like this. I don't know because most
of the time I use that feature it is only because of things like
upgrading file formats and such where the program editing the file
actually renames the file to a new file extension. I've never actually
tried this "vendor branch" feature.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3066498
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-17 15:45:33 CEST