Chia-liang Kao wrote:
> Folker Schamel <schamel23 <at> spinor.com> writes:
>
>>We came accross that issue because currently we have a long living branch.
>>We regulary merge from trunk (having trivial scripts managing
>>the last merged revision).
>>And due to refactoring, several files are renamed in the branch.
>>So we encountered that issue.
>
>
> Actually you can use svk to do the merge. Just add a depot map, say
> 'project', to the existing subversion repository, and run
>
> svk merge -rN:M --track-rename /project/trunk /project/branches/mybranch
>
> This is also how I generate the perl bindings backport patch for 1.0.x
> branch, since there were reorganization of the tree some while ago.
Yes, svk looks very nice!
And indeed I took a look at svk some time ago.
In this case not because of merging, but because of
off-line laptop work.
The hurdle is that the svk wc format is not compatible
to the svn wc format.
For daily work this means that you cannot use TortoiseSVN.
Using svk for merging only means that you need an additional working copy
in the svk format, which means extra compiling time you have to keep
up-to-date only for merging.
Our scripts are very simple, but do their job,
so this seems to be the easier solution in our case.
> There is no rename tracking support for 'svk smerge' yet, because the
> ancestor and source can be on different branches, and there's
> currently no way to inject rename information for svn_repos_dir_delta.
>
> Why is --track-renmae not default? Because it's an expensive
> operation. svk has to harvest renames up to last merge points with
> svn_fs_node_history, and see if any of the ancestors are deleted in
> the same revision. Yes, there's no true rename support, but that's
> what we have now.
>
> ghudson said on IRC that it is possible to add APIs to extract copy
> ancestors efficiently without schema changes. We definitely need this
> as a prerequisite for proper merge support in svn.
My impression is that it will take its time, but svn will go its way!
And I understand completely that things like locking currently
have higher priority.
Just for interest:
What's the reason that svk is not part of svn?
svk functionality being part of svn would be a dream!!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 6 01:10:50 2004