You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@gmail.com> on 2015/03/13 18:13:18 UTC
Playing with svnmover
Dear fans of move tracking,
I heartily invite you to help by playing with 'svnmover'. Can you have
a go and see what it can do? It's quite fun to play with (in a nerdy
way :-)
To get it, build the 'move-tracking-2' branch and look in
'subversion/svnmover/svnmover' -- it's a sibling to 'svn' and
'svnmucc'.
It's fairly easy to pick up as you go along. There's a transcript
below, as an example. You can also see in the IRC history [1] where I
guided Brane through playing with it for the first time.
You can try
- doing renames/moves (using 'mv PATH1 PATH2')
- merging those changes onto another branch ('merge FROM TO YCA')
- visualize what's happening ('branches PATH', 'ls PATH', 'ls-br-r')
- type 'help' to see usage message
You should find that it copes perfectly with renames inside renames, and so on.
Do please share any thoughts or questions you have --
* about the model
* do you grok the way moves work in svnmover?
* any new feature 'svnmover' should have to help with experimenting?
I believe we can build a move-tracking design for Subversion. This
stage is not trying to give the final answer, it is squarely aimed at
exploring and understanding how it could and should work. So I need
*your* input, please, if you can spare some thought cycles and
experimentation cycles.
Here's an example transcript.
[[[
$ svnadmin create repo; REPO=file://$PWD/repo
$ svnmover -U $REPO
svnmover> ls .
e0 .
svnmover> mkbranch trunk mkdir branches
A trunk (branch ^.2)
A branches
Committed r1:
--- diff branch ^, family 0, at / : /
A e2 e0/trunk (branch ^.2)
A e3 e0/branches
--- added branch ^.2, family 1, at /trunk
svnmover> mkdir trunk/A mkdir trunk/A/D1 mkdir trunk/A/D2
A trunk/A
A trunk/A/D1
A trunk/A/D2
Committed r2:
--- diff branch ^.2, family 1, at /trunk : /trunk
A e101 e100/A
A e102 e101/D1
A e103 e101/D2
svnmover> branch trunk branches/br1
A+ branches/br1 (branch ^.4)
Committed r3:
--- diff branch ^, family 0, at / : /
A e4 e3/br1 (branch ^.4)
--- added branch ^.4, family 1, at /branches/br1
svnmover> branches .
branches in family 0:
^ /
svnmover> branches trunk
branches in family 1:
^.2 /trunk
^.4 /branches/br1
svnmover> mv branches/br1/A/D1 branches/br1/D1renamed
V branches/br1/D1renamed (from branches/br1/A/D1)
Committed r4:
--- diff branch ^.4, family 1, at /branches/br1 : /branches/br1
Mvr e102 e100/D1renamed from e101/D1
svnmover> mkdir trunk/A/D1/new-child
A trunk/A/D1/new-child
Committed r5:
--- diff branch ^.2, family 1, at /trunk : /trunk
A e104 e102/new-child
svnmover> merge trunk branches/br1 trunk@2
A e104 new-child
Committed r6:
--- diff branch ^.4, family 1, at /branches/br1 : /branches/br1
A e104 e102/new-child
svnmover> ls branches/br1
e100 .
e101 A
e102 D1renamed
e103 A/D2
e104 D1renamed/new-child
svnmover> merge branches/br1 trunk trunk@2
M/V e102 D1renamed
M/V e104 new-child
Committed r7:
--- diff branch ^.2, family 1, at /trunk : /trunk
Mvr e102 e100/D1renamed from e101/D1
svnmover> ls trunk
e100 .
e101 A
e102 D1renamed
e103 A/D2
e104 D1renamed/new-child
svnmover>
]]]
- Julian
[1] <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-05#l113>
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 25, 2015 at 6:01 PM, Julian Foad <ju...@gmail.com> wrote:
> Bert Huijben wrote:
>> Julian, you can just force the windows Ra bot to build a/this/your branch
>> via IRC if you want to verify if it works now. (The Ra bot uses a shared
>> library build, like Johan's environment. The local bot a static library
>> version)
>
>
> Thanks, Bert. That helps. After a couple of tries and fixes, the
> buildbot has built the code now (and is running the regression tests,
> which don't matter so much as a successful build).
>
Great, I can build it too now. Now onto playing :-) ...
--
Johan
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Bert Huijben wrote:
> Julian, you can just force the windows Ra bot to build a/this/your branch
> via IRC if you want to verify if it works now. (The Ra bot uses a shared
> library build, like Johan's environment. The local bot a static library
> version)
Thanks, Bert. That helps. After a couple of tries and fixes, the
buildbot has built the code now (and is running the regression tests,
which don't matter so much as a successful build).
- Julian
RE: Playing with svnmover
Posted by Bert Huijben <be...@qqmail.nl>.
Julian, you can just force the windows Ra bot to build a/this/your branch via IRC if you want to verify if it works now. (The Ra bot uses a shared library build, like Johan's environment. The local bot a static library version)
Bert
-----Original Message-----
From: "Julian Foad" <ju...@gmail.com>
Sent: 25-3-2015 10:00
To: "Johan Corveleyn" <jc...@gmail.com>
Cc: "Bert Huijben" <be...@qqmail.nl>; "dev" <de...@subversion.apache.org>
Subject: Re: Playing with svnmover
On 24 March 2015 at 22:50, Johan Corveleyn <jc...@gmail.com> wrote:
> But now I'm running into a new one:
>
> [[[
> svn_ra-1.lib(ra_loader.obj) : error LNK2019: unresolved external
> symbol _svn_delta__get_debug_editor referenced in function
> _svn_ra_get_commit_editor_ev3
[...]
> ]]]
>
> I suppose the problem is that svn_delta_get_debug_editor is being
> referenced from libsvn_ra/ra_loader.c, but it is only defined in
> debug_editor.h which is private to libsvn_delta. It seems it was
> introduced on the move-tracking-2 branch in r1634591.
Hi Johan. Yes. It's only used to print debug messages. For now, I've
just commented out the calls to it in r1669075.
Sorry again for the difficulties.
If you run into any more undefined symbols, try pinging IRC first, to
see if there is anybody online who can help resolve the issue
immediately. It's a pity you had to wait ten hours for me to respond
on email.
- Julian
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
On 24 March 2015 at 22:50, Johan Corveleyn <jc...@gmail.com> wrote:
> But now I'm running into a new one:
>
> [[[
> svn_ra-1.lib(ra_loader.obj) : error LNK2019: unresolved external
> symbol _svn_delta__get_debug_editor referenced in function
> _svn_ra_get_commit_editor_ev3
[...]
> ]]]
>
> I suppose the problem is that svn_delta_get_debug_editor is being
> referenced from libsvn_ra/ra_loader.c, but it is only defined in
> debug_editor.h which is private to libsvn_delta. It seems it was
> introduced on the move-tracking-2 branch in r1634591.
Hi Johan. Yes. It's only used to print debug messages. For now, I've
just commented out the calls to it in r1669075.
Sorry again for the difficulties.
If you run into any more undefined symbols, try pinging IRC first, to
see if there is anybody online who can help resolve the issue
immediately. It's a pity you had to wait ten hours for me to respond
on email.
- Julian
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Mar 19, 2015 at 12:42 PM, Julian Foad <ju...@gmail.com> wrote:
> Johan Corveleyn wrote:
>> Another step further, but now I get this (don't really understand why):
>>
>> [[[
>> libsvn_delta.def : error LNK2001: unresolved external symbol
>> svn_editor3__insert_shims
>
> That function is declared in svn_editor3e.h and never defined nor referenced.
>
> Rather than debug why it's reported as an unresolved symbol, I have
> removed the declaration in r1667708.
>
>> libsvn_delta.def : error LNK2001: unresolved external symbol
>> svn_editor3p_res
>
> svn_editor3p_res() is only ever defined and referenced inside #ifdef
> SVN_EDITOR3_WITH_RESURRECTION ... and that should not be defined. Is
> the problem caused by the MSVC project generator detecting this
> declaration in the header file, even though it's ifdef'd out, and then
> telling MSVC to 'export' it even though it's not defined? If so, for
> now, can you just delete its declaration locally?
>
> I guess that would also explain svn_editor3__insert_shims().
Yes, that's it. When I delete the declaration of svn_editor3p_res()
from private/svn_editor3p.h locally, I get past that error.
But now I'm running into a new one:
[[[
svn_ra-1.lib(ra_loader.obj) : error LNK2019: unresolved external
symbol _svn_delta__get_debug_editor referenced in function
_svn_ra_get_commit_editor_ev3
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_ra_dll.vcxproj]
C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_ra\libsvn_ra-1.dll
: fatal error LNK1120: 1 unresolved externals
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_ra_dll.vcxproj]
]]]
I suppose the problem is that svn_delta_get_debug_editor is being
referenced from libsvn_ra/ra_loader.c, but it is only defined in
debug_editor.h which is private to libsvn_delta. It seems it was
introduced on the move-tracking-2 branch in r1634591.
--
Johan
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Johan Corveleyn wrote:
> Another step further, but now I get this (don't really understand why):
>
> [[[
> libsvn_delta.def : error LNK2001: unresolved external symbol
> svn_editor3__insert_shims
That function is declared in svn_editor3e.h and never defined nor referenced.
Rather than debug why it's reported as an unresolved symbol, I have
removed the declaration in r1667708.
> libsvn_delta.def : error LNK2001: unresolved external symbol
> svn_editor3p_res
svn_editor3p_res() is only ever defined and referenced inside #ifdef
SVN_EDITOR3_WITH_RESURRECTION ... and that should not be defined. Is
the problem caused by the MSVC project generator detecting this
declaration in the header file, even though it's ifdef'd out, and then
telling MSVC to 'export' it even though it's not defined? If so, for
now, can you just delete its declaration locally?
I guess that would also explain svn_editor3__insert_shims().
- Julian
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Mar 19, 2015 at 1:21 AM, Julian Foad <ju...@gmail.com> wrote:
> Bert Huijben wrote:
>> Johan Corveleyn wrote:
>>> Thanks. I get a bit further now. But now it fails with some linker problems:
>>>
>>> [[[
>>> svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
>>> symbol _svn_editor3p__insert_shims referenced in funct[...]
>>
>> I'm guessing this is caused by a missing msvc-export = <new-header> definition in build.conf.
>>
>> Without that new functions are not exported from .DLLs on Windows.
>
> Hi Johan. Try after r1667644 please, where I've added the new headers
> to the 'msvc-export'. Hope I did it right. Sorry for all the fuss just
> to get it built.
Another step further, but now I get this (don't really understand why):
[[[
libsvn_delta.def : error LNK2001: unresolved external symbol
svn_editor3__insert_shims
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta_dll.vcxproj]
libsvn_delta.def : error LNK2001: unresolved external symbol
svn_editor3p_res
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta_dll.vcxproj]
C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_delta\libsvn_delta-1.lib
: fatal error LNK1120: 2 unresolved externals
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta_dll.vcxproj]
]]]
No problem that this takes some time to get right. It's also an
exercise for me :-), to get back into active development, trying to
understand the build system etc ... there is no rush, but I'm looking
around a bit ...
--
Johan
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Bert Huijben wrote:
> Johan Corveleyn wrote:
>> Thanks. I get a bit further now. But now it fails with some linker problems:
>>
>> [[[
>> svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
>> symbol _svn_editor3p__insert_shims referenced in funct[...]
>
> I'm guessing this is caused by a missing msvc-export = <new-header> definition in build.conf.
>
> Without that new functions are not exported from .DLLs on Windows.
Hi Johan. Try after r1667644 please, where I've added the new headers
to the 'msvc-export'. Hope I did it right. Sorry for all the fuss just
to get it built.
Thanks, Bert, for the diagnosis.
- Julian
Re: Generating msvc-export Re: Playing with svnmover
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Thu, Mar 19, 2015 at 07:14:57 +0000:
> It won't be hard to turn it into a tools/dev/ script that automatically
> edits build.conf to add anything that's missing, if anyone thinks that's
> a good idea...
I have in mind a script that developers can run locally before
committing. That is, the workflow would be:
% svn add subversion/include/private/svn_foo.h
% tools/dev/the-new-script # adds svn_foo.h to build.conf
% svn commit
Generating msvc-export Re: Playing with svnmover
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Bert Huijben wrote on Thu, Mar 19, 2015 at 00:44:02 +0100:
> > [[[
> > svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
> > symbol _svn_editor3p__insert_shims referenced in funct
> > ion _svn_repos_get_commit_editor5
> > [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vcproj\libsvn_repos_dll.vcxpro
> > j]
> > C:\research\svn\dev\move-tracking-
> > 2\Debug\subversion\libsvn_repos\libsvn_repos-1.dll
> > : fatal error LNK1120: 1 unresolve
> > d externals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vcproj\libsvn_repos_dll.vcxproj]
> > ...
> > svn_wc-1.lib(update_editor.obj) : error LNK2019: unresolved external
> > symbol _svn_delta__ev3_from_delta_for_update refer
> > enced in function _make_editor3
> > [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vcproj\libsvn_wc_dll.vcxproj]
> > svn_wc-1.lib(deprecated.obj) : error LNK2019: unresolved external
> > symbol _svn_delta__delta_from_ev3_for_update referenc
> > ed in function _svn_wc_get_update_editor4
> > [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vcproj\libsvn_wc_dll.v
> > cxproj]
> > C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_wc\libsvn_wc-
> > 1.dll
> > : fatal error LNK1120: 2 unresolved exte
> > rnals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vcproj\libsvn_wc_dll.vcxproj]
> > ]]]
>
> I'm guessing this is caused by a missing msvc-export = <new-header> definition in build.conf.
>
> Without that new functions are not exported from .DLLs on Windows.
For what it's worth, here are a pair of scripts that can be used
together to generate a list of headers missing from msvc-export for
a given library.
That's just a proof-of-concept, in particular, it depends on having
an up-to-date tags file in the source tree.
Here is how it works:
% cd root-of-trunk-working-copy
% ctags -R ./
% ./extract-msvc-export.py libsvn_wc
subversion/include/private/svn_wc_private.h
subversion/include/svn_wc.h
% ./compute-msvc-export.py libsvn_wc
subversion/include/private/svn_wc_private.h
subversion/include/svn_wc.h
% list-headers-missing-from-msvc-export-for() { ./extract-msvc-export.py $1 >1; ./compute-msvc-export.py $1 >2; diff 1 2; rm 1 2 }
% list-headers-missing-from-msvc-export-for libsvn_subr
18a19
> subversion/include/private/svn_pseudo_md5.h
This example shows the script correctly determined that svn_pseudo_md5.h
declares functions that are defined in libsvn_subr, but is not listed in
the msvc-export setting for that library.�
It won't be hard to turn it into a tools/dev/ script that automatically
edits build.conf to add anything that's missing, if anyone thinks that's
a good idea...
Daniel
� That svn_pseudo_md5.h discrepancy doesn't break the windows build
because, currently, nothing that uses libsvn_subr.dll uses that header.
RE: Playing with svnmover
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: donderdag 19 maart 2015 00:32
> To: Julian Foad
> Cc: dev
> Subject: Re: Playing with svnmover
>
> On Wed, Mar 18, 2015 at 10:09 AM, Julian Foad <ju...@gmail.com>
> wrote:
> > Johan Corveleyn wrote:
> >>> I intend to take a closer look soon. But as you know, my definition of
> >>> "soon" is a bit ... vague ;-).
> >>>
> >>> I greatly appreciate your efforts to get "move support" ... moving in svn.
> >>
> >> First hurdle: I have trouble compiling it (on Windows 7, VS 2013).
> >> Both with "release" and with "debug" configuration:
> >
> > Thank you for having a go! Sorry about these troubles.
> >
> >> 1) Debug configuration
> >>
> >> [[[
> >> ..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2121: '#' :
> >> invalid character : possibly the result of a macro expansion [...]
> >
> > My bad. I used #ifdef inside the parameters of an SVN_ERR macro invocation.
> >
> > Fixed in r1667473.
>
> Thanks. I get a bit further now. But now it fails with some linker problems:
>
> [[[
> svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
> symbol _svn_editor3p__insert_shims referenced in funct
> ion _svn_repos_get_commit_editor5
> [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> vcproj\libsvn_repos_dll.vcxpro
> j]
> C:\research\svn\dev\move-tracking-
> 2\Debug\subversion\libsvn_repos\libsvn_repos-1.dll
> : fatal error LNK1120: 1 unresolve
> d externals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> vcproj\libsvn_repos_dll.vcxproj]
> ...
> svn_wc-1.lib(update_editor.obj) : error LNK2019: unresolved external
> symbol _svn_delta__ev3_from_delta_for_update refer
> enced in function _make_editor3
> [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> vcproj\libsvn_wc_dll.vcxproj]
> svn_wc-1.lib(deprecated.obj) : error LNK2019: unresolved external
> symbol _svn_delta__delta_from_ev3_for_update referenc
> ed in function _svn_wc_get_update_editor4
> [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> vcproj\libsvn_wc_dll.v
> cxproj]
> C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_wc\libsvn_wc-
> 1.dll
> : fatal error LNK1120: 2 unresolved exte
> rnals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> vcproj\libsvn_wc_dll.vcxproj]
> ]]]
I'm guessing this is caused by a missing msvc-export = <new-header> definition in build.conf.
Without that new functions are not exported from .DLLs on Windows.
Bert
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 18, 2015 at 10:09 AM, Julian Foad <ju...@gmail.com> wrote:
> Johan Corveleyn wrote:
>>> I intend to take a closer look soon. But as you know, my definition of
>>> "soon" is a bit ... vague ;-).
>>>
>>> I greatly appreciate your efforts to get "move support" ... moving in svn.
>>
>> First hurdle: I have trouble compiling it (on Windows 7, VS 2013).
>> Both with "release" and with "debug" configuration:
>
> Thank you for having a go! Sorry about these troubles.
>
>> 1) Debug configuration
>>
>> [[[
>> ..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2121: '#' :
>> invalid character : possibly the result of a macro expansion [...]
>
> My bad. I used #ifdef inside the parameters of an SVN_ERR macro invocation.
>
> Fixed in r1667473.
Thanks. I get a bit further now. But now it fails with some linker problems:
[[[
svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
symbol _svn_editor3p__insert_shims referenced in funct
ion _svn_repos_get_commit_editor5
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_repos_dll.vcxpro
j]
C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_repos\libsvn_repos-1.dll
: fatal error LNK1120: 1 unresolve
d externals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_repos_dll.vcxproj]
...
svn_wc-1.lib(update_editor.obj) : error LNK2019: unresolved external
symbol _svn_delta__ev3_from_delta_for_update refer
enced in function _make_editor3
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_wc_dll.vcxproj]
svn_wc-1.lib(deprecated.obj) : error LNK2019: unresolved external
symbol _svn_delta__delta_from_ev3_for_update referenc
ed in function _svn_wc_get_update_editor4
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_wc_dll.v
cxproj]
C:\research\svn\dev\move-tracking-2\Debug\subversion\libsvn_wc\libsvn_wc-1.dll
: fatal error LNK1120: 2 unresolved exte
rnals [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_wc_dll.vcxproj]
]]]
--
Johan
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Johan Corveleyn wrote:
>> I intend to take a closer look soon. But as you know, my definition of
>> "soon" is a bit ... vague ;-).
>>
>> I greatly appreciate your efforts to get "move support" ... moving in svn.
>
> First hurdle: I have trouble compiling it (on Windows 7, VS 2013).
> Both with "release" and with "debug" configuration:
Thank you for having a go! Sorry about these troubles.
> 1) Debug configuration
>
> [[[
> ..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2121: '#' :
> invalid character : possibly the result of a macro expansion [...]
My bad. I used #ifdef inside the parameters of an SVN_ERR macro invocation.
Fixed in r1667473.
> 2) Release configuration (maybe it's not necessary to be able to build
> it in release configuration at this point, but I'm mentioning it here
> for completeness)
>
> [[[
> ..\..\..\subversion\libsvn_delta\branch.c(582): error C4013: 'SVN_DBG'
> undefined; ...
I've knowingly left SVN_DBG statements in the code: it's not intended
to be compiled in release mode.
Thanks again!
- Julian
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 18, 2015 at 3:15 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Mar 17, 2015 at 4:17 PM, Julian Foad <ju...@gmail.com> wrote:
>> On 13 March 2015, Julian Foad wrote:
>>> Dear fans of move tracking,
>>>
>>> I heartily invite you to help by playing with 'svnmover'. Can you have
>>> a go and see what it can do? It's quite fun to play with (in a nerdy
>>> way :-)
>>
>> One unimplemented bit you might come across is 'svnmover merge'
>> doesn't try to merge file content. It reports a conflict if file
>> content (text and/or props) needs merging. That's simply because it
>> isn't directly relevant to the move logic so I didn't bother to
>> implement it yet; we can use directories instead of files, or files
>> without content changes, to test the move logic. Please feel free to
>> add text and props merging code near the comment
>>
>> /* ### Need not conflict if can merge props and text separately. */
>>
>> in svnmover.c:element_merge(), if you fancy doing so.
>>
>> Anyone tried or planning to try this, yet?
>>
>
> I intend to take a closer look soon. But as you know, my definition of
> "soon" is a bit ... vague ;-).
>
> I greatly appreciate your efforts to get "move support" ... moving in svn.
>
First hurdle: I have trouble compiling it (on Windows 7, VS 2013).
Both with "release" and with "debug" configuration:
1) Debug configuration
[[[
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2121: '#' :
invalid character : possibly the result of a macro
expansion [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2065: 'ifdef'
: undeclared identifier [C:\research\svn\dev\mov
e-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2440:
'function' : cannot convert from 'int' to 'svn_pathrev_t
' [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C4024:
'svn_editor3p_cp' : different types for formal and actua
l parameter 2 [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2146: syntax
error : missing ')' before identifier 'SVN_EDITOR
3_WITH_COPY_FROM_THIS_REV'
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2198:
'svn_editor3p_cp' : too few arguments for call [C:\resea
rch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(836): error C2143: syntax
error : missing '{' before '*' [C:\research\svn\d
ev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
]]]
I might look more into this later, but I thought I'd already mention it here.
2) Release configuration (maybe it's not necessary to be able to build
it in release configuration at this point, but I'm mentioning it here
for completeness)
[[[
..\..\..\subversion\libsvn_delta\branch.c(582): error C4013: 'SVN_DBG'
undefined; assuming extern returning int [C:\res
earch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3e.c(883): error C4013:
'SVN_DBG' undefined; assuming extern returning int [C:\r
esearch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3e.c(1200): error C4013:
'peg_path_str' undefined; assuming extern returning int
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3e.c(1200): error C4047: ':' :
'int' differs in levels of indirection from 'char
[6]' [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3e.c(1395): error C4047: ':' :
'int' differs in levels of indirection from 'char
[6]' [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2121: '#' :
invalid character : possibly the result of a macro
expansion [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2065: 'ifdef'
: undeclared identifier [C:\research\svn\dev\mov
e-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2440:
'function' : cannot convert from 'int' to 'svn_pathrev_t
' [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C4024:
'svn_editor3p_cp' : different types for formal and actua
l parameter 2 [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2146: syntax
error : missing ')' before identifier 'SVN_EDITOR
3_WITH_COPY_FROM_THIS_REV'
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(783): error C2198:
'svn_editor3p_cp' : too few arguments for call [C:\resea
rch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(810): error C4013:
'SVN_DBG' undefined; assuming extern returning int [C:\r
esearch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_delta\compat3p.c(836): error C2143: syntax
error : missing '{' before '*' [C:\research\svn\d
ev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_delta.vcxproj]
..\..\..\subversion\libsvn_ra_local\ra_plugin.c(1055): error C4013:
'SVN_DBG' undefined; assuming extern returning int
[C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_ra_local.vcxproj]
..\..\..\subversion\libsvn_ra\ra_loader.c(708): error C4013: 'SVN_DBG'
undefined; assuming extern returning int [C:\res
earch\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_ra.vcxproj]
..\..\..\subversion\libsvn_ra\ra_loader.c(1011): error C4013:
'svn_dbg__quiet_mode' undefined; assuming extern returnin
g int [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_ra.vcxproj]
..\..\..\subversion\libsvn_wc\update_editor.c(5104): error C4013:
'SVN_DBG' undefined; assuming extern returning int [C
:\research\svn\dev\move-tracking-2\build\win32\vcnet-vcproj\libsvn_wc.vcxproj]
]]]
--
Johan
Re: Playing with svnmover
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Mar 17, 2015 at 4:17 PM, Julian Foad <ju...@gmail.com> wrote:
> On 13 March 2015, Julian Foad wrote:
>> Dear fans of move tracking,
>>
>> I heartily invite you to help by playing with 'svnmover'. Can you have
>> a go and see what it can do? It's quite fun to play with (in a nerdy
>> way :-)
>
> One unimplemented bit you might come across is 'svnmover merge'
> doesn't try to merge file content. It reports a conflict if file
> content (text and/or props) needs merging. That's simply because it
> isn't directly relevant to the move logic so I didn't bother to
> implement it yet; we can use directories instead of files, or files
> without content changes, to test the move logic. Please feel free to
> add text and props merging code near the comment
>
> /* ### Need not conflict if can merge props and text separately. */
>
> in svnmover.c:element_merge(), if you fancy doing so.
>
> Anyone tried or planning to try this, yet?
>
I intend to take a closer look soon. But as you know, my definition of
"soon" is a bit ... vague ;-).
I greatly appreciate your efforts to get "move support" ... moving in svn.
--
Johan
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
On 13 March 2015, Julian Foad wrote:
> Dear fans of move tracking,
>
> I heartily invite you to help by playing with 'svnmover'. Can you have
> a go and see what it can do? It's quite fun to play with (in a nerdy
> way :-)
One unimplemented bit you might come across is 'svnmover merge'
doesn't try to merge file content. It reports a conflict if file
content (text and/or props) needs merging. That's simply because it
isn't directly relevant to the move logic so I didn't bother to
implement it yet; we can use directories instead of files, or files
without content changes, to test the move logic. Please feel free to
add text and props merging code near the comment
/* ### Need not conflict if can merge props and text separately. */
in svnmover.c:element_merge(), if you fancy doing so.
Anyone tried or planning to try this, yet?
- Julian
>
> To get it, build the 'move-tracking-2' branch and look in
> 'subversion/svnmover/svnmover' -- it's a sibling to 'svn' and
> 'svnmucc'.
>
> It's fairly easy to pick up as you go along. There's a transcript
> below, as an example. You can also see in the IRC history [1] where I
> guided Brane through playing with it for the first time.
>
> You can try
>
> - doing renames/moves (using 'mv PATH1 PATH2')
> - merging those changes onto another branch ('merge FROM TO YCA')
> - visualize what's happening ('branches PATH', 'ls PATH', 'ls-br-r')
> - type 'help' to see usage message
>
> You should find that it copes perfectly with renames inside renames, and so on.
>
> Do please share any thoughts or questions you have --
>
> * about the model
>
> * do you grok the way moves work in svnmover?
>
> * any new feature 'svnmover' should have to help with experimenting?
>
> I believe we can build a move-tracking design for Subversion. This
> stage is not trying to give the final answer, it is squarely aimed at
> exploring and understanding how it could and should work. So I need
> *your* input, please, if you can spare some thought cycles and
> experimentation cycles.
>
>
>
> Here's an example transcript.
[...]
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Julian Foad wrote:
> On 7 April 2015 at 21:59, Stefan Fuhrmann wrote:
>> * Trying to rename a sub-branch root:
>> svnmover> mv trunk/sub trunk/A
>> mv: moving by copy-and-delete
>> svnmover: warning: apr_err=SVN_ERR_ASSERTION_FAIL
>> svnmover: warning: W235000: In file 'subversion/libsvn_delta/editor3e.c'
>> line 293: assertion failed (eid != branch->sibling_defn->root_eid)
>
> OK, there's a bug. This move should just work, no need for
> 'copy-and-delete'. What's happening is a confusion over whether the
> move source is identified as 'the root element of branch <trunk/sub>'
> or as 'the element named <sub> in branch <trunk>'.
>
> I'm working on it.
Fixed in r1672160.
This fix caused the 'restructure repo: projects/ttb to ttb/projects'
test to fail, because the way it used the 'mv' command relied on the
broken behaviour. So now I need to provide an alternative UI for the
behaviour that test needs.
I noticed another bug:
'svnmover merge' doesn't raise a conflict when one side deletes a
directory and the other side changed something within that directory.
I think that is a simple omission in the merge implementation.
- Julian
Re: Playing with svnmover
Posted by Julian Foad <ju...@gmail.com>.
Hi Stefan. Thanks for this set of feedback.
On 7 April 2015 at 21:59, Stefan Fuhrmann wrote:
[...]
> The only major problem IMO, is that "branchify" is currently
> too destructive: Applied within an existing branch, it seems
> to make merges from & to the respective sub-tree impossible
Yes, indeed, the current 'branchify' is quite destructive.
> I think I have a solution to that and will sketch that in a
> separate post.
That will be interesting to discuss.
> * nice to have: svnmover should have a history in interactive mode
OK, done in r1672066, by importing and using the 'linenoise' project.
> * Local paths don't get resolved as expect:
> svnmover> put ~/develop/svnmover/mail.txt trunk/sub/mail.txt
> svnmover: warning: apr_err=ENOENT
> svnmover: warning: W000002: Can't open file '~/develop/svnmover/mail.txt':
> No such file or directory
> svnmover> put /home/stefan/develop/svnmover/mail.txt trunk/sub/mail.txt
> svnmover: warning: apr_err=SVN_ERR_INCORRECT_PARAMS
> svnmover: warning: W200004: Argument
> '/home/stefan/develop/svnmover/mail.txt' is not a relative path or a URL
Fixed in r1672070. The 'put' command is the only command that accesses
a local path. An absolute path is now allowed here. ('~' is still not
recognized as a special symbol.)
> * Trying to branch from a non-branch-root segfaults:
> svnmover> branch trunk branches/maint
> Segmentation fault (core dumped)
(Where 'trunk' is not a branch-root, in this example.)
Fixed in r1672086.
> * Are element IDs arbitrary? From the output it seems that they use
> distinct ranges for each branch. I assume a "proper" implementation
> would have a two-dimensional ID space such as "e1.1" instead of "e101".
Each branch family has its own set of element ids that is in a
different 'name space' ('number space' if you like) from each other
family.
The element ids within a family are completely arbitrary. Currently
they are generated by a counter, so are sequential, but this is not
necessary. I made the counter in each family start from (100 *
family-number) for ease of reference by us humans. See '#define
PRETTY_IDS' in branch.c near line 162; undefining this makes them
start from 0 in each family.
The ids are already in a two-dimensional id space: (family-id, element-id).
> * Bogus error message when trying to create a sub-branch from a non-branch-root:
> svnmover> branch trunk/sub trunk/B
> svnmover: warning: W123456: source and destination must be within same
> outer branch; source is b10 inside b0, destination is in b10
> svnmover> ls .
> e0 .
> e1 branches
> e3 tags
> e6 trunk (branch ^.6)
> e7 branches/maint (branch ^.7)
> svnmover> ls trunk
> e100 .
> e101 sub
> e102 sub/mail.txt
This is by design. (I've made the error message a bit clearer in r1672086.)
In the current model, branching a subtree (of an existing branch)
means making a new branch, and the new branch must be *alongside* the
existing branch not *inside* it. The new branch is indeed a branch of
the selected subtree, but this operation does not convert the subtree
into a *subbranch*.
A subbranch is a member of a separate branch family. Branching a
subtree of an existing branch, on the other hand, creates another
branch in the same family.
> * Currently, branchify cannot "heal" or "undo" a dissolve operation.
> Can that limitation be lifted for any copy source / target pair?
> Can that limitation be lifted for undoing a 'dissolve' when no
> other commits were done to that (former) branch in the meantime?
Let's discuss 'branchify' in a separate thread.
> * Trying to rename a sub-branch root:
> svnmover> mv trunk/sub trunk/A
> mv: moving by copy-and-delete
> svnmover: warning: apr_err=SVN_ERR_ASSERTION_FAIL
> svnmover: warning: W235000: In file 'subversion/libsvn_delta/editor3e.c'
> line 293: assertion failed (eid != branch->sibling_defn->root_eid)
OK, there's a bug. This move should just work, no need for
'copy-and-delete'. What's happening is a confusion over whether the
move source is identified as 'the root element of branch <trunk/sub>'
or as 'the element named <sub> in branch <trunk>'.
I'm working on it.
[...]
> * The following sequence works, though (ommitting outputs):
> svnmover> branch trunk/sub trunk/B
> svnmover> branch trunk/sub trunk/A
> svnmover> rm trunk/sub
>
> Interesting state of branches/maint/sub vs. trunk/A & trunk/B:
> svnmover> ls-br-r
> [[[
[...]
> family 1 (BSIDs 10:12, EIDs 100:106)
> branch ^.6 bsid=10 root=e100 /trunk
> e100 .
> e104 B (branch ^.6.104)
> e105 A (branch ^.6.105)
> branch ^.7 bsid=11 root=e100 /branches/maint
> e100 .
> e101 sub
> e102 sub/mail.txt
> family 2 (BSIDs 20:23, EIDs 200:202)
> branch ^.6.104 bsid=21 root=e200 /trunk/B
> e200 .
> e201 mail.txt
> branch ^.6.105 bsid=22 root=e200 /trunk/A
> e200 .
> e201 mail.txt
> ]]]
When you say 'interesting state' I suppose you are remarking on the
fact that trunk/A and trunk/B are subbranches (in family 2) whereas
branches/maint/sub is not.
The 'branchify' command replaced the original subtree at 'trunk/sub'
with a subbranch also at path 'trunk/sub'. By design, it did not
replace the corresponding subtree at 'branches/maint/sub'...
> * Trying to merge a recent change:
> svnmover> merge branches/maint trunk trunk@6
> ! e102 <conflict>
> svnmover: warning: W123456: Merge failed: conflict(s) occurred
[...]
> * Merging into the opposite direction fails as well:
[...]
> How would that kind of conflict be permanently resolved?
... and so we get conflicts like this (which are of the kind "modified
versus disappeared"). Let's take this discussion to a new thread about
'branchify'.
- Julian
Re: Playing with svnmover
Posted by Stefan Fuhrmann <st...@wandisco.com>.
Hi Julian,
Here the things that I noticed while playing with svnmover.
I was going for a FSFS / FSX library duplication scenario.
The only major problem IMO, is that "branchify" is currently
too destructive: Applied within an existing branch, it seems
to make merges from & to the respective sub-tree impossible
(but the conflict it might also have been caused by the
deletion, so I'm not 100% positive).
I think I have a solution to that and will sketch that in a
separate post.
-- Stefan^2.
* nice to have: svnmover should have a history in interactive mode
* Local paths don't get resolved as expect:
svnmover> put ~/develop/svnmover/mail.txt trunk/sub/mail.txt
svnmover: warning: apr_err=ENOENT
svnmover: warning: W000002: Can't open file
'~/develop/svnmover/mail.txt': No such file or directory
svnmover> put /home/stefan/develop/svnmover/mail.txt trunk/sub/mail.txt
svnmover: warning: apr_err=SVN_ERR_INCORRECT_PARAMS
svnmover: warning: W200004: Argument
'/home/stefan/develop/svnmover/mail.txt' is not a relative path or a URL
* Trying to branch from a non-branch-root segfaults:
svnmover> branch trunk branches/maint
Segmentation fault (core dumped)
* Are element IDs arbitrary? From the output it seems that they use
distinct ranges for each branch. I assume a "proper" implementation
would have a two-dimensional ID space such as "e1.1" instead of "e101".
* Bogus error message when trying to create a sub-branch from a
non-branch-root:
svnmover> branch trunk/sub trunk/B
svnmover: warning: W123456: source and destination must be within same
outer branch; source is b10 inside b0, destination is in b10
svnmover> ls .
e0 .
e1 branches
e3 tags
e6 trunk (branch ^.6)
e7 branches/maint (branch ^.7)
svnmover> ls trunk
e100 .
e101 sub
e102 sub/mail.txt
* Currently, branchify cannot "heal" or "undo" a dissolve operation.
Can that limitation be lifted for any copy source / target pair?
Can that limitation be lifted for undoing a 'dissolve' when no
other commits were done to that (former) branch in the meantime?
* Trying to rename a sub-branch root:
svnmover> mv trunk/sub trunk/A
mv: moving by copy-and-delete
svnmover: warning: apr_err=SVN_ERR_ASSERTION_FAIL
svnmover: warning: W235000: In file 'subversion/libsvn_delta/editor3e.c'
line 293: assertion failed (eid != branch->sibling_defn->root_eid)
Tree structure before & after (unchanged):
svnmover> ls-br-r
family 0 (BSIDs 0:1, EIDs 0:8)
branch ^ bsid=0 root=e0 /
e0 .
e1 branches
e3 tags
e6 trunk (branch ^.6)
e7 branches/maint (branch ^.7)
family 1 (BSIDs 10:12, EIDs 100:104)
branch ^.6 bsid=10 root=e100 /trunk
e100 .
e103 sub (branch ^.6.103)
branch ^.7 bsid=11 root=e100 /branches/maint
e100 .
e101 sub
e102 sub/mail.txt
family 2 (BSIDs 20:21, EIDs 200:202)
branch ^.6.103 bsid=20 root=e200 /trunk/sub
e200 .
e201 mail.txt
* The following sequence works, though (ommitting outputs):
svnmover> branch trunk/sub trunk/B
svnmover> branch trunk/sub trunk/A
svnmover> rm trunk/sub
Interesting state of branches/maint/sub vs. trunk/A & trunk/B:
svnmover> ls-br-r
[[[
family 0 (BSIDs 0:1, EIDs 0:8)
branch ^ bsid=0 root=e0 /
e0 .
e1 branches
e3 tags
e6 trunk (branch ^.6)
e7 branches/maint (branch ^.7)
family 1 (BSIDs 10:12, EIDs 100:106)
branch ^.6 bsid=10 root=e100 /trunk
e100 .
e104 B (branch ^.6.104)
e105 A (branch ^.6.105)
branch ^.7 bsid=11 root=e100 /branches/maint
e100 .
e101 sub
e102 sub/mail.txt
family 2 (BSIDs 20:23, EIDs 200:202)
branch ^.6.104 bsid=21 root=e200 /trunk/B
e200 .
e201 mail.txt
branch ^.6.105 bsid=22 root=e200 /trunk/A
e200 .
e201 mail.txt
]]]
* Trying to merge a recent change:
svnmover> merge branches/maint trunk trunk@6
! e102 <conflict>
svnmover: warning: W123456: Merge failed: conflict(s) occurred
I guess that merge has been doomed since the point trunk/sub
became a branch root.
* Merging into the opposite direction fails as well:
svnmover> merge trunk branches/maint trunk@6
D e101 sub
! e102 <conflict>
A e104 B (branch ^.6.104)
A e105 A (branch ^.6.105)
svnmover: warning: W123456: Merge failed: conflict(s) occurred
How would that kind of conflict be permanently resolved?
Full log:
svnmover> log .@0 .@12
[[[
------------------------------------------------------------------------
r12 | ...
Changed elements:
--- diff branch ^.6 at /trunk : ^.6 at /trunk, family 1
D sub (branch ^.6.103)
--- deleted branch ^.6.103, family 2, at /trunk/sub
------------------------------------------------------------------------
r11 | ...
Changed elements:
--- diff branch ^.6 at /trunk : ^.6 at /trunk, family 1
A A (branch ^.6.105)
--- added branch ^.6.105, family 2, at /trunk/A
------------------------------------------------------------------------
r10 | ...
Changed elements:
--- diff branch ^.6 at /trunk : ^.6 at /trunk, family 1
A B (branch ^.6.104)
--- added branch ^.6.104, family 2, at /trunk/B
------------------------------------------------------------------------
r9 | ...
Changed elements:
--- diff branch ^.6 at /trunk : ^.6 at /trunk, family 1
D sub
D sub/mail.txt
A sub (branch ^.6.103)
--- added branch ^.6.103, family 2, at /trunk/sub
------------------------------------------------------------------------
r8 | ...
Changed elements:
--- diff branch ^.7 at /branches/maint : ^.7 at /branches/maint, family 1
M sub/mail.txt
------------------------------------------------------------------------
r7 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A branches/maint (branch ^.7)
--- added branch ^.7, family 1, at /branches/maint
------------------------------------------------------------------------
r6 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
D trunk
D trunk/sub
D trunk/sub/mail.txt
A trunk (branch ^.6)
--- added branch ^.6, family 1, at /trunk
------------------------------------------------------------------------
r5 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A trunk/sub/mail.txt
------------------------------------------------------------------------
r4 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A trunk/sub
------------------------------------------------------------------------
r3 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A tags
------------------------------------------------------------------------
r2 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A trunk
------------------------------------------------------------------------
r1 | ...
Changed elements:
--- diff branch ^ at / : ^ at /, family 0
A branches
]]]