Merge tracking between several parallel branches
I have some questions regarding the status of the merge tracking functionality in subversion 1.6. Based on my understanding, it seems like svn has good “automatic” support for merging between branches in one direction, whereas cyclic/bidirectional merging requires a more complex “reintegrate” + “record only” merge procedure. I am wondering if this support also extends to scenarios with repeated merging between several parallel release branches. Does svn handle arbitrary "directed acyclic" merging between several parallel branches, when merging is always conducted in the same direction (e.g. from old to newer release branch)? Does the “reintegrate” + “record only” merge procedure extend gracefully to scenarios with arbitrary cyclic/bidirectional merging between several parallel branches? Thanks in advance, Fredrik Orderud
Problems with empty svn:date revprops (github svnsync)
I'm experiencing problems using svnsync to mirror a GitHub repo. GitHub exposes a SVN API, that enables SVN clients to work against the underlying GIT repo ( https://help.github.com/articles/support-for-subversion-clients/). This mostly works great, but I'm struggling to combine it with synsync. The problem seem to be caused by Github defining empty svn:author, svn:date & svn:log revision properties for rev 0. The empty svn:date revision property causes problems for svnsync, since empty svn:date properties are apparently invalid. Example error when attempting to use svnsync to sync a GitHub repo to a separate SVN repo: svnsync: E175008: While handling the 'svn:date' property on '/svn/mirror_repo/!svn/bln/0': svnsync: E175008: Wrong or unexpected property value Could it be possible to somehow make svn:date parsing more permissive, so that empty svn:date revision properties does not break svnsync? Thanks in advance, Fredrik Orderud
Re: Problems with empty svn:date revprops (github svnsync)
Thanks for the tips Nico. I am well aware that git-svn sync can be troublesome and best avoided if possible. The planned syncing will be one-way, against a read-only svn mirror repo maintained for "corporate policy" reasons. GitHub have already been contacted regarding the issue, but I thought it also made sense to investigate opportunities for fixes from the svn side. In my view, empty revprops should not cause svnsync to fail this way. Best regards, Fredrik On Tuesday, October 27, 2015, Nico Kadel-Garcia wrote: > On Tue, Oct 27, 2015 at 9:03 AM, Fredrik Orderud > wrote: > > I'm experiencing problems using svnsync to mirror a GitHub repo. > > > > GitHub exposes a SVN API, that enables SVN clients to work against the > > underlying GIT repo > > (https://help.github.com/articles/support-for-subversion-clients/). This > > mostly works great, but I'm struggling to combine it with synsync. > > That's an impedance mismatch begging to happen. Why would you attempt > to keep *any* non-matching source control synced with an external > repository, except possibly for imports of third-party tags? Been > there, done that for a stock exchange years ago. I urge you not to > try: grab tags only from the third party, copy and update your old > tags to match the new import, tag that so you can report differences > between them, and move in. Don't bother to try to maintain log parity, > you'll hurt yourself. > > > The problem seem to be caused by Github defining empty svn:author, > svn:date > > & svn:log revision properties for rev 0. The empty svn:date revision > > property causes problems for svnsync, since empty svn:date properties are > > apparently invalid. > > See above. It sounds like you need to talk to Github about making an > exception to their default settings for revision 0. A freshly > initialized git repo, with no files or property changes submitted, has > *no* valid logs, and "git log" fails with an error. A freshly > initialized svn repo, with no files or properties set, has a no logs > but has a revision "0" created at index time. > > Like I just said: impedance mismatch. > > > Example error when attempting to use svnsync to sync a GitHub repo to a > > separate SVN repo: > > svnsync: E175008: While handling the 'svn:date' property on > > '/svn/mirror_repo/!svn/bln/0': > > svnsync: E175008: Wrong or unexpected property value > > > > Could it be possible to somehow make svn:date parsing more permissive, so > > that empty svn:date revision properties does not break svnsync? > > Seems conceivable, but you might get to real work much faster by > resetting svn:date in your local repository as part of the mirroring > process from github. Or even, perhaps, using "svnadmin create" to > create an empty repository of the same version as your mirror setup, > and using a template repo/db/revprops/0/0 with a pre-set, ancient > date. This is a complete violation of the provenence of the > repository, but I think it's survivable. > > > Thanks in advance, > > Fredrik Orderud >
Merge order affects final result for repeated added & deleted changes
There seems to be a problem with the merge logic in SVN when merging repeated added & deleted changes out-of-order. Example activity on branch A: r1: A new file is added. r2: A line is added r3: The line is removed r4: The line is re-added Later activity on branch B (created from A@r1): r5: r2 and r4 are merged in. r6: r3 is merged in. What happens in r5 is that repeated merging of the same change does _not_ cause duplication or merge conflict. Instead, r4 seems to be ignored. The end result after r6 (a complete merge) is that r4 is missing from branch B. This is inconsistent with svn:mergeinfo which claims that it has been merged. Patches to reproduce are attached. Could it be possible to make svn merges fail on repeated merges of the same change, instead of just ignoring them? The problem was reproduced using svn 1.8.1 (command-line) client on Win7 64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win server 2008 R2. Thanks in advance, Fredrik Orderud Index: Test.cpp === --- Test.cpp(revision 0) +++ Test.cpp(revision 1) @@ -0,0 +1 @@ +First line Index: Test.cpp === --- Test.cpp(revision 1) +++ Test.cpp(revision 2) @@ -1 +1,2 @@ First line +Second line Index: Test.cpp === --- Test.cpp(revision 2) +++ Test.cpp(revision 3) @@ -1,2 +1 @@ First line -Second line Index: Test.cpp === --- Test.cpp(revision 3) +++ Test.cpp(revision 4) @@ -1 +1,2 @@ First line +Second line
Re: Merge order affects final result for repeated added & deleted changes
On Tue, Aug 6, 2013 at 10:05 AM, Johan Corveleyn wrote: > Yes, go ahead and file an issue, and include links to this and the other > mail thread in the description. > > At this point, I am not sure whether I'd call it a defect or an > enhancement request (asking for a new optional strict mode for merging), I > guess it depends on your point of view. But it doesn't matter that much, so > go with what you think is best. > Thanks! I took the liberty of categorizing it as a "defect" and registered http://subversion.tigris.org/issues/show_bug.cgi?id=4405 Please let me know if there is anything else I can do to increase the likelihood of this issue being fixed as soon as reasonably possible. Best, Fredrik
