Merge rename tracking

[Chia-liang Kao <cl...@clkao.org>]

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.

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.

Cheers,
CLK

Re: Merge rename tracking

[Folker Schamel <sc...@spinor.com>]

> On Mon, Sep 06, 2004 at 01:08:30AM +0200, Folker Schamel wrote:
> 
>>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.
> 
> 
> Not quite true, svk supports external merge tool:
> 
>   http://wagner.elixus.org/~clkao/svk-intro/slide14a.html
> 
> Which also means you can perform merge in-place, without a working
> copy.  So basically there's no overhead if you just want to use svk
> for rename-aware merging, while keep using svn for all the other
> things.

In our case we need a test compile before committing the merge.
This test compile basically always shows up minor bugs
caused by merging but having not shown up by conflicts.
(E.g. utilify function AAA renamed to BBB in branch1,
but a new call to function AAA added in a different file in branch2.)

> But I guess in your case the real hurdle would be svk doesn't work
> fully on win32 yet.  It's being worked on and has very nice progress
> at the status of self-hosting..

Is there anywere information about the status of svk on win32?
I cannot find something about it on svk.elixus.org.

>>Just for interest:
>>What's the reason that svk is not part of svn?
>>
>>svk functionality being part of svn would be a dream!!
> 
> 
> Well, I'm just implementing what I need, and it happens to be useful
> for some people too.  For now people who want extremely disconnected
> working environment and/or advanced merge features can use svk when
> they need it.  Switching back and forth from/to svn is painless.
> 
> Meanwhile I have no problem if people are going to implement what svk
> offers back in svn, and I'm all for help, since it means other people
> will be taking care of something useful to me!  But it's going be a
> lot of work, and that's why I didn't do it in C.  (I'll stop here
> instead of cursing the wc code :)





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Merge rename tracking

[Chia-liang Kao <cl...@clkao.org>]

On Mon, Sep 06, 2004 at 01:08:30AM +0200, Folker Schamel wrote:
> 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.

Not quite true, svk supports external merge tool:

  http://wagner.elixus.org/~clkao/svk-intro/slide14a.html

Which also means you can perform merge in-place, without a working
copy.  So basically there's no overhead if you just want to use svk
for rename-aware merging, while keep using svn for all the other
things.

But I guess in your case the real hurdle would be svk doesn't work
fully on win32 yet.  It's being worked on and has very nice progress
at the status of self-hosting..

> Just for interest:
> What's the reason that svk is not part of svn?
> 
> svk functionality being part of svn would be a dream!!

Well, I'm just implementing what I need, and it happens to be useful
for some people too.  For now people who want extremely disconnected
working environment and/or advanced merge features can use svk when
they need it.  Switching back and forth from/to svn is painless.

Meanwhile I have no problem if people are going to implement what svk
offers back in svn, and I'm all for help, since it means other people
will be taking care of something useful to me!  But it's going be a
lot of work, and that's why I didn't do it in C.  (I'll stop here
instead of cursing the wc code :)

Cheers,
CLK

Re: Merge rename tracking

[Folker Schamel <sc...@spinor.com>]

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