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)
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
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 >
Re: Problems with empty svn:date revprops (github svnsync)
On 27.10.2015 14:33, Nico Kadel-Garcia wrote: > 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. There's no such thing as "impedance mismatch" when you're implementing a wire protocol. if GitHub provides an SVN/HTTP protocol endpoint but don't emulate a valid r0, then that's no more and no less than a bug in their protocol implementation. It doesn't matter that they're using Git in the back-end. -- Brane
Re: Problems with empty svn:date revprops (github svnsync)
On 27.10.2015 15:18, Fredrik Orderud wrote: > 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. Not all revprops are created equal. Subversion has required a valid, non-empty svn:date on every revision since before 1.0. I can sympathise with your frustration, but it would really not serve anyone's best interests if we changed that assumption 15 years down the road just because there's a bug in some implementation of the protocol. FWIW, in my experience GitHub have a good record of fixing such bugs once they're reported. -- Brane
Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
Dear list, Linux Mint ( see http://www.linuxmint.com ) seems to be a variant of Ubuntu Linux. "uname -a" says Linux [hostname] 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux and "cat /etc/issue" says Linux Mint 17.2 Rafaela I've successfully installed Eclipse 3.8.1 (debbuild) via the application manager. Next, being root, I've updated eclipse with their built-in system. Worked seemingly. Now, according to that page: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA the first thing I need to do is install JavaHL, right? http://subclipse.tigris.org/wiki/JavaHL#head-bb1dd50f9ec2f0d8c32246430c00e237d27a04fe # apt-get install libsvn-java works fine. I get the resulting location # find / -name libsvnjavahl-1.so /usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so So when I try to test Java as suggested after having downloaded the javahltests.jar file. When issueing # java -Djava.library.path=/usr/lib/x86_64-linux-gnu/jni -jar javahltests.jar or # java -Djava.library.path=/usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so -jar javahltests.jar I get 50 errors, so 100% failure. Looks encouraging! Unfortunately the howto does not say where to go from there. Looking for answers in the web was not very helpful as there seem to exist a plethora of versions of anything.. When I've installed subclipse several years ago, it has been equally straining - I know that I need to enter the URL subclipse.tigris.org in one of the next steps in order to install subclipse, but I don't know which version. I've seen there is a table on this page: http://subclipse.tigris.org/wiki/JavaHL - so I guess that as I have svn commandline client 1.8.8, I will need the tigris subclipse URL 1.10.x? Als a svn commandline client, I have svn 1.8.8 installed. Later, I'd like to access a svn server with version 1.6 Thanks a lot.. *sigh* Andreas <>
Re: Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
The wiki is pretty clear that the tests linked on that page are only good with SVN 1.6. If you are determined to run the tests you need to get them from SVN. They are not our tests. Mark > On Oct 27, 2015, at 12:32 PM, Andreas Delleske wrote: > > Dear list, > > Linux Mint ( see http://www.linuxmint.com ) seems to be a variant of > Ubuntu Linux. "uname -a" says > > Linux [hostname] 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > and "cat /etc/issue" says > > Linux Mint 17.2 Rafaela > > I've successfully installed Eclipse 3.8.1 (debbuild) via the application > manager. Next, being root, I've updated eclipse with their built-in > system. Worked seemingly. > > Now, according to that page: > > http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA > > the first thing I need to do is install JavaHL, right? > > http://subclipse.tigris.org/wiki/JavaHL#head-bb1dd50f9ec2f0d8c32246430c00e237d27a04fe > > # apt-get install libsvn-java > > works fine. I get the resulting location > > # find / -name libsvnjavahl-1.so > /usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so > > So when I try to test Java as suggested after having downloaded the > javahltests.jar file. When issueing > > # java -Djava.library.path=/usr/lib/x86_64-linux-gnu/jni -jar > javahltests.jar > > or > > # java > -Djava.library.path=/usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so -jar > javahltests.jar > > I get 50 errors, so 100% failure. Looks encouraging! > > Unfortunately the howto does not say where to go from there. > > Looking for answers in the web was not very helpful as there seem to > exist a plethora of versions of anything.. > > When I've installed subclipse several years ago, it has been equally > straining - I know that I need to enter the URL subclipse.tigris.org in > one of the next steps in order to install subclipse, but I don't know > which version. > > I've seen there is a table on this page: > > http://subclipse.tigris.org/wiki/JavaHL > > - so I guess that as I have svn commandline client 1.8.8, I will need > the tigris subclipse URL 1.10.x? > > > Als a svn commandline client, I have svn 1.8.8 installed. Later, I'd > like to access a svn server with version 1.6 > > Thanks a lot.. > > *sigh* > > Andreas > > >
Re: Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
Dear Mark, thanks for answering so fast! > The wiki is pretty clear that the tests linked on that page are only good > with SVN 1.6. I have SVN server 1.6 - I was not sure if that counts, apparently not. So what could be the next steps - ignore the test and add Subclipse 1.10 (for svn client 1.8) - http://subclipse.tigris.org/update_1.10.x to the list of repositories in Eclipse and install? That's what I did (still being root) - now Eclipse wants to restart, then wants my confirmation that it might the GNOME keyring bug. I confirmed. Is that it? I think I did the same on my company's computer, the "Team" menu had been added, project can be checked out but checking out our project from the SVN server stops in the middle of the transaction (lengthy project with 100-200 MBytes reporoductibly without any message - while I am able to "svn co" the same project with svn commandline client.. Eclipse seems to work, but throws lot of these. [..] java version "1.7.0_79" OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1) OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode) Okt 27, 2015 5:46:52 PM org.apache.commons.httpclient.HttpMethodBase processCookieHeaders WARNUNG: Cookie rejected: "$Version=0; JSESSIONID=8B06EEBB429BF8DBFD5788055CDB3F20; $Path=/servlets". Illegal path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" Okt 27, 2015 5:47:14 PM org.apache.commons.httpclient.HttpMethodBase processCookieHeaders WARNUNG: Cookie rejected: "$Version=0; JSESSIONID=B92847B1AC91926EDBA04298E8BAB425; $Path=/servlets". Illegal path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" Okt 27, 2015 5:47:15 PM org.apache.commons.httpclient.HttpMethodBase processCookieHeaders WARNUNG: Cookie rejected: "$Version=0; JSESSIONID=53DC53FE046B20A198058FBC9C363C7E; $Path=/servlets". Illegal path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" Vector smash protection is enabled. java version "1.7.0_79" OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1) OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode) ** (Eclipse:11030): CRITICAL **: gboolean webkit_dom_mouse_event_get_alt_key(WebKitDOMMouseEvent*): assertion 'WEBKIT_DOM_IS_MOUSE_EVENT(self)' failed The last line is repeated about a hundred times.. Andreas
Re: Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
On Tue, Oct 27, 2015 at 12:56 PM, Andreas Delleske wrote: > Dear Mark, > > thanks for answering so fast! > > > The wiki is pretty clear that the tests linked on that page are only > good with SVN 1.6. > > I have SVN server 1.6 - I was not sure if that counts, apparently not. > > So what could be the next steps - ignore the test and add > > Subclipse 1.10 (for svn client 1.8) - > http://subclipse.tigris.org/update_1.10.x > > to the list of repositories in Eclipse and install? > Yes, or install it from the Eclipse Marketplace Client (which just does that for you). > That's what I did (still being root) - now Eclipse wants to restart, > then wants my confirmation that it might the GNOME keyring bug. I > confirmed. Is that it? > The dialog is telling you there is a bug in GNOME keyring and that it needs to disable that feature. This is fixed in SVN 1.8.11+ > > I think I did the same on my company's computer, the "Team" menu had > been added, project can be checked out but checking out our project from > the SVN server stops in the middle of the transaction (lengthy project > with 100-200 MBytes reporoductibly without any message - while I am able > to "svn co" the same project with svn commandline client.. > Not sure I follow this part, but if a project is already checked out you can use Eclipse File > Import > Existing Projects into Workspace to add it to Eclipse. If it is already in Eclipse, you can use Team > Share to "connect" it with SVN plugin. > > Eclipse seems to work, but throws lot of these. > > [..] > java version "1.7.0_79" > OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1) > OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode) > Okt 27, 2015 5:46:52 PM org.apache.commons.httpclient.HttpMethodBase > processCookieHeaders > WARNUNG: Cookie rejected: "$Version=0; > JSESSIONID=8B06EEBB429BF8DBFD5788055CDB3F20; $Path=/servlets". Illegal > path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" > Okt 27, 2015 5:47:14 PM org.apache.commons.httpclient.HttpMethodBase > processCookieHeaders > WARNUNG: Cookie rejected: "$Version=0; > JSESSIONID=B92847B1AC91926EDBA04298E8BAB425; $Path=/servlets". Illegal > path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" > Okt 27, 2015 5:47:15 PM org.apache.commons.httpclient.HttpMethodBase > processCookieHeaders > WARNUNG: Cookie rejected: "$Version=0; > JSESSIONID=53DC53FE046B20A198058FBC9C363C7E; $Path=/servlets". Illegal > path attribute "/servlets". Path of origin: "/update_1.10.x/p2.index" > These are not significant. > Vector smash protection is enabled. > java version "1.7.0_79" > OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1) > OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode) > > ** (Eclipse:11030): CRITICAL **: gboolean > webkit_dom_mouse_event_get_alt_key(WebKitDOMMouseEvent*): assertion > 'WEBKIT_DOM_IS_MOUSE_EVENT(self)' failed > These would be Eclipse SWT messages. There have been a lot of GTK fixes in newer Eclipse versions since 3.8. Could be worth trying Eclipse 4.5.1. That said other than noting these messages in the log I am not sure what problem it is you are running into or trying to solve. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
Dear Mark, >> So what could be the next steps - ignore the test and add >> >> Subclipse 1.10 (for svn client 1.8) - >> http://subclipse.tigris.org/update_1.10.x >> >> to the list of repositories in Eclipse and install? >> > > Yes, or install it from the Eclipse Marketplace Client (which just does > that for you). OK that's good news to me! I'll repeat the steps on my work computer tomorrow and report.. > The dialog is telling you there is a bug in GNOME keyring and that it needs > to disable that feature. This is fixed in SVN 1.8.11+ OK thanks.. > These are not significant. Thanks again! > There have been a lot of GTK fixes in newer Eclipse versions since 3.8. > Could be worth trying Eclipse 4.5.1. Ah OK - from here I guess? https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/mars/1/eclipse-cpp-mars-1-linux-gtk-x86_64.tar.gz I really hope the tar.gz does not mess up my Linux Mint.. and I guess I uninstall eclipse-cdt from Linux Mint first..? > That said other than noting these > messages in the log I am not sure what problem it is you are running into > or trying to solve. I'll try all the steps tomorrow and report back if there are errors or if it's solved - thank you very much so far! Andreas
Re: Problems with empty svn:date revprops (github svnsync)
Branko Čibej writes: > Subversion has required a valid, > non-empty svn:date on every revision since before 1.0. Subversion also allows revisions without an svn:date. It is possible to delete svn:date and it is possible for path-based authz to make the date invisible. svnsync will cope with this. The problem is this case is an invalid date is present and that is not allowed. The work around is to skip the init step by manually setting svn:sync-from-url, svn:sync-from-uuid and svn:sync-last-merged-rev. -- Philip Martin WANdisco
Re: Subclipse on Eclipse 3.8 on Linux Mint 17.2 (Ubuntu)
If you install from tar, it will presumably just be a folder in your home directory. It does not have any bearing on the packages from your distro. You do not have to uninstall the eclipse-cdt package. If the latest version works better then you could certainly do so, but there is no need to do it as a pre-req. You will need to install any plugins etc. in the new version. So you will have to install Subclipse. You will not have to install the JavaHL package again though since you already did that. Mark On Tue, Oct 27, 2015 at 1:13 PM, Andreas Delleske wrote: > Dear Mark, > > >> So what could be the next steps - ignore the test and add > >> > >> Subclipse 1.10 (for svn client 1.8) - > >> http://subclipse.tigris.org/update_1.10.x > >> > >> to the list of repositories in Eclipse and install? > >> > > > > Yes, or install it from the Eclipse Marketplace Client (which just does > > that for you). > > OK that's good news to me! > > I'll repeat the steps on my work computer tomorrow and report.. > > > The dialog is telling you there is a bug in GNOME keyring and that it > needs > > to disable that feature. This is fixed in SVN 1.8.11+ > > OK thanks.. > > > These are not significant. > > Thanks again! > > > There have been a lot of GTK fixes in newer Eclipse versions since 3.8. > > Could be worth trying Eclipse 4.5.1. > > Ah OK - from here I guess? > > > https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/mars/1/eclipse-cpp-mars-1-linux-gtk-x86_64.tar.gz > > I really hope the tar.gz does not mess up my Linux Mint.. and I guess I > uninstall eclipse-cdt from Linux Mint first..? > > > That said other than noting these > > messages in the log I am not sure what problem it is you are running into > > or trying to solve. > > I'll try all the steps tomorrow and report back if there are errors or > if it's solved - thank you very much so far! > > Andreas > > > -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Problems with empty svn:date revprops (github svnsync)
On Tue, Oct 27, 2015 at 12:07 PM, Branko Čibej wrote: > On 27.10.2015 14:33, Nico Kadel-Garcia wrote: >> 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. > > There's no such thing as "impedance mismatch" when you're implementing a > wire protocol. if GitHub provides an SVN/HTTP protocol endpoint but I assume that you *are* aware that the phrase "impedance mismatch" comes from actual circuitry with actual wires, right? The irony is pretty funny, especially since my background is bio-electrical engineering. When one protocol has different specifics than the other protocol, you most certainly *can* have what I'd call an "impedance mismatch". Data that is required by convention for the initial setup is a great example. Others include the arbitrary, procedural convention of branches and tags in Subversion, and the software embedded support for them in git, and the ability to checkout out only a small portion of a Subversion repository as a working copy, versus the need to clone the entire repository for local git working copies. Being a "wire protocol" doesn't fix that. > don't emulate a valid r0, then that's no more and no less than a bug in > their protocol implementation. It doesn't matter that they're using Git > in the back-end. I agree this is a bug. But the bug seems to be most noticeable because "revision 0" needs special handling for doing a reliable svnsync setup. It doesn't seem necessary for running a local working copy, and trying to run an svnsync and rely on it presents quite a few more fascinating potential mismatches.
