{"thread":{"id":"27126","subject":"[PATCH] remove noise and inaccuracies from git-svn docs","startedAt":"2011-04-18T14:46:40Z","lastAt":"2011-05-05T20:33:19Z","messageCount":16,"participants":["Stefan Sperling","Matthieu Moy","Junio C Hamano","Michael J Gruber","Piotr Krukowiecki","Michael Schubert","Matthew L Daniel","Sverre Rabbelier","Matthew Daniel"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"166035","messageId":"1303138000-27807-1-git-send-email-stsp@stsp.name","threadId":"27126","inReplyTo":null,"subject":"[PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-18T14:46:40Z","receivedAt":"2011-04-18T14:46:40Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"---\n Documentation/git-svn.txt |   16 +++++++---------\n 1 files changed, 7 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex ea8fafd..a3b4c91 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -757,10 +757,9 @@ use `git svn rebase` to update your work branch instead of `git pull` or\n when committing into SVN, which can lead to merge commits reversing\n previous commits in SVN.\n \n-DESIGN PHILOSOPHY\n------------------\n-Merge tracking in Subversion is lacking and doing branched development\n-with Subversion can be cumbersome as a result.  While 'git svn' can track\n+MERGE TRACKING\n+--------------\n+While 'git svn' can track\n copy history (including branches and tags) for repositories adopting a\n standard layout, it cannot yet represent merge history that happened\n inside git back upstream to SVN users.  Therefore it is advised that\n@@ -770,16 +769,15 @@ compatibility with SVN (see the CAVEATS section below).\n CAVEATS\n -------\n \n-For the sake of simplicity and interoperating with a less-capable system\n-(SVN), it is recommended that all 'git svn' users clone, fetch and dcommit\n+For the sake of simplicity and interoperating with Subversion,\n+it is recommended that all 'git svn' users clone, fetch and dcommit\n directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push'\n operations between git repositories and branches.  The recommended\n method of exchanging code between git branches and users is\n 'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository.\n \n Running 'git merge' or 'git pull' is NOT recommended on a branch you\n-plan to 'dcommit' from.  Subversion does not represent merges in any\n-reasonable or useful fashion; so users using Subversion cannot see any\n+plan to 'dcommit' from because Subversion users cannot see any\n merges you've made.  Furthermore, if you merge or pull from a git branch\n that is a mirror of an SVN branch, 'dcommit' may commit to the wrong\n branch.\n@@ -829,7 +827,7 @@ Renamed and copied directories are not detected by git and hence not\n tracked when committing to SVN.  I do not plan on adding support for\n this as it's quite difficult and time-consuming to get working for all\n the possible corner cases (git doesn't do it, either).  Committing\n-renamed and copied files are fully supported if they're similar enough\n+renamed and copied files is fully supported if they're similar enough\n for git to detect them.\n \n CONFIGURATION\n-- \n1.7.3.5\n"},{"id":"166037","messageId":"vpqhb9vplu4.fsf@bauges.imag.fr","threadId":"27126","inReplyTo":"1303138000-27807-1-git-send-email-stsp@stsp.name","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-04-18T16:26:27Z","receivedAt":"2011-04-18T16:26:27Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stefan Sperling <stsp@stsp.name> writes:\n\n> -DESIGN PHILOSOPHY\n> ------------------\n> -Merge tracking in Subversion is lacking and doing branched development\n> -with Subversion can be cumbersome as a result.  While 'git svn' can\n> track\n\nAgreed (this and the rest of the patch). Users reading git-svn's doc\ndon't want a dissertation about how bad SVN is, and if they do, they can\nread whygitisbetterthanx ;-)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"166038","messageId":"7v39lfa1h5.fsf@alter.siamese.dyndns.org","threadId":"27126","inReplyTo":"vpqhb9vplu4.fsf@bauges.imag.fr","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-18T17:55:18Z","receivedAt":"2011-04-18T17:55:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Stefan Sperling <stsp@stsp.name> writes:\n>\n>> -DESIGN PHILOSOPHY\n>> ------------------\n>> -Merge tracking in Subversion is lacking and doing branched development\n>> -with Subversion can be cumbersome as a result.  While 'git svn' can\n>> track\n>\n> Agreed (this and the rest of the patch). Users reading git-svn's doc\n> don't want a dissertation about how bad SVN is, and if they do, they can\n> read whygitisbetterthanx ;-)\n\nI agree the change in the patch is good.  It needs to be signed-off,\nthough.\n"},{"id":"166070","messageId":"1303204006-24191-1-git-send-email-stsp@stsp.name","threadId":"27126","inReplyTo":"7v39lfa1h5.fsf@alter.siamese.dyndns.org","subject":"[PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-19T09:06:46Z","receivedAt":"2011-04-19T09:06:46Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"Signed-off-by: Stefan Sperling <stsp@stsp.name>\n---\n Documentation/git-svn.txt |   16 +++++++---------\n 1 files changed, 7 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 4aa6404..fedf310 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -767,10 +767,9 @@ use `git svn rebase` to update your work branch instead of `git pull` or\n when committing into SVN, which can lead to merge commits reversing\n previous commits in SVN.\n \n-DESIGN PHILOSOPHY\n------------------\n-Merge tracking in Subversion is lacking and doing branched development\n-with Subversion can be cumbersome as a result.  While 'git svn' can track\n+MERGE TRACKING\n+--------------\n+While 'git svn' can track\n copy history (including branches and tags) for repositories adopting a\n standard layout, it cannot yet represent merge history that happened\n inside git back upstream to SVN users.  Therefore it is advised that\n@@ -780,16 +779,15 @@ compatibility with SVN (see the CAVEATS section below).\n CAVEATS\n -------\n \n-For the sake of simplicity and interoperating with a less-capable system\n-(SVN), it is recommended that all 'git svn' users clone, fetch and dcommit\n+For the sake of simplicity and interoperating with Subversion,\n+it is recommended that all 'git svn' users clone, fetch and dcommit\n directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push'\n operations between git repositories and branches.  The recommended\n method of exchanging code between git branches and users is\n 'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository.\n \n Running 'git merge' or 'git pull' is NOT recommended on a branch you\n-plan to 'dcommit' from.  Subversion does not represent merges in any\n-reasonable or useful fashion; so users using Subversion cannot see any\n+plan to 'dcommit' from because Subversion users cannot see any\n merges you've made.  Furthermore, if you merge or pull from a git branch\n that is a mirror of an SVN branch, 'dcommit' may commit to the wrong\n branch.\n@@ -839,7 +837,7 @@ Renamed and copied directories are not detected by git and hence not\n tracked when committing to SVN.  I do not plan on adding support for\n this as it's quite difficult and time-consuming to get working for all\n the possible corner cases (git doesn't do it, either).  Committing\n-renamed and copied files are fully supported if they're similar enough\n+renamed and copied files is fully supported if they're similar enough\n for git to detect them.\n \n CONFIGURATION\n-- \n1.7.3.5\n"},{"id":"166074","messageId":"20110419093108.GA7440@ted.stsp.name","threadId":"27126","inReplyTo":"7v39lfa1h5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-19T09:31:08Z","receivedAt":"2011-04-19T09:31:08Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"On Mon, Apr 18, 2011 at 10:55:18AM -0700, Junio C Hamano wrote:\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n> \n> > Stefan Sperling <stsp@stsp.name> writes:\n> >\n> >> -DESIGN PHILOSOPHY\n> >> ------------------\n> >> -Merge tracking in Subversion is lacking and doing branched development\n> >> -with Subversion can be cumbersome as a result.  While 'git svn' can\n> >> track\n> >\n> > Agreed (this and the rest of the patch). Users reading git-svn's doc\n> > don't want a dissertation about how bad SVN is, and if they do, they can\n> > read whygitisbetterthanx ;-)\n\nExactly :)\n\nAnd they might rather want to learn more about how Subversion has improved\nsince version 1.4. It seems that these parts of the text were written\nbefore Subversion's 1.5 release. SVN is a lot more capable now than the\ngit-svn docs suggest and I'm surprised that git-svn's development seems\nto have gotten stuck at the 1.4 level of functionality. Not even CentOS\nships with 1.4 anymore these days.\n\nE.g. git-svn could be taught to generate svn mergeinfo compatible with other\nSubversion clients. It's not easy to come up with a generic mapping between\nthe two systems but for some use cases it should be reasonably straightforward.\nThis would be a nice improvement towards making git-svn a proper drop-in\nreplacement for the standard svn client. Currently, git-svn cannot be\nused without disturbing other users doing merges with Subversion itself\nwhich is a pity.\n\nI don't have time to work on this myself but I would be more than happy\nto assist with design and review.\n\n> I agree the change in the patch is good.  It needs to be signed-off,\n> though.\n\nI've sent a signed-off version with git send-email. Thanks!\n"},{"id":"166078","messageId":"4DAD6FC4.6060004@drmicha.warpmail.net","threadId":"27126","inReplyTo":"20110419093108.GA7440@ted.stsp.name","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-19T11:19:32Z","receivedAt":"2011-04-19T11:19:32Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Stefan Sperling venit, vidit, dixit 19.04.2011 11:31:\n> On Mon, Apr 18, 2011 at 10:55:18AM -0700, Junio C Hamano wrote:\n>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>>\n>>> Stefan Sperling <stsp@stsp.name> writes:\n>>>\n>>>> -DESIGN PHILOSOPHY\n>>>> ------------------\n>>>> -Merge tracking in Subversion is lacking and doing branched development\n>>>> -with Subversion can be cumbersome as a result.  While 'git svn' can\n>>>> track\n>>>\n>>> Agreed (this and the rest of the patch). Users reading git-svn's doc\n>>> don't want a dissertation about how bad SVN is, and if they do, they can\n>>> read whygitisbetterthanx ;-)\n> \n> Exactly :)\n> \n> And they might rather want to learn more about how Subversion has improved\n> since version 1.4. It seems that these parts of the text were written\n> before Subversion's 1.5 release. SVN is a lot more capable now than the\n> git-svn docs suggest and I'm surprised that git-svn's development seems\n> to have gotten stuck at the 1.4 level of functionality. Not even CentOS\n> ships with 1.4 anymore these days.\n> \n> E.g. git-svn could be taught to generate svn mergeinfo compatible with other\n> Subversion clients. It's not easy to come up with a generic mapping between\n> the two systems but for some use cases it should be reasonably straightforward.\n> This would be a nice improvement towards making git-svn a proper drop-in\n> replacement for the standard svn client. Currently, git-svn cannot be\n> used without disturbing other users doing merges with Subversion itself\n> which is a pity.\n\n6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)\n\nmade a first step in that direction so that you can at least add\nmergeinfo manually. But, git-svn.perl is basically in maintenance mode\nit seems, and more work is being done to implement a new svn remote helper.\n\nAlso, I think merge tracking wasn't that reliable in svn 1.5 before svn\n1.6, and we try to support older versions. In particular, we want to\nsupport the versions on typical svn hosting sites which are not always\nthat recent.\n\n> \n> I don't have time to work on this myself but I would be more than happy\n> to assist with design and review.\n> \n>> I agree the change in the patch is good.  It needs to be signed-off,\n>> though.\n> \n> I've sent a signed-off version with git send-email. Thanks!\n"},{"id":"166080","messageId":"20110419120031.GE4134@ted.stsp.name","threadId":"27126","inReplyTo":"4DAD6FC4.6060004@drmicha.warpmail.net","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-19T12:00:31Z","receivedAt":"2011-04-19T12:00:31Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"On Tue, Apr 19, 2011 at 01:19:32PM +0200, Michael J Gruber wrote:\n> Stefan Sperling venit, vidit, dixit 19.04.2011 11:31:\n> > On Mon, Apr 18, 2011 at 10:55:18AM -0700, Junio C Hamano wrote:\n> >> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n> >>\n> >>> Stefan Sperling <stsp@stsp.name> writes:\n> >>>\n> >>>> -DESIGN PHILOSOPHY\n> >>>> ------------------\n> >>>> -Merge tracking in Subversion is lacking and doing branched development\n> >>>> -with Subversion can be cumbersome as a result.  While 'git svn' can\n> >>>> track\n> >>>\n> >>> Agreed (this and the rest of the patch). Users reading git-svn's doc\n> >>> don't want a dissertation about how bad SVN is, and if they do, they can\n> >>> read whygitisbetterthanx ;-)\n> > \n> > Exactly :)\n> > \n> > And they might rather want to learn more about how Subversion has improved\n> > since version 1.4. It seems that these parts of the text were written\n> > before Subversion's 1.5 release. SVN is a lot more capable now than the\n> > git-svn docs suggest and I'm surprised that git-svn's development seems\n> > to have gotten stuck at the 1.4 level of functionality. Not even CentOS\n> > ships with 1.4 anymore these days.\n> > \n> > E.g. git-svn could be taught to generate svn mergeinfo compatible with other\n> > Subversion clients. It's not easy to come up with a generic mapping between\n> > the two systems but for some use cases it should be reasonably straightforward.\n> > This would be a nice improvement towards making git-svn a proper drop-in\n> > replacement for the standard svn client. Currently, git-svn cannot be\n> > used without disturbing other users doing merges with Subversion itself\n> > which is a pity.\n> \n> 6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)\n> \n> made a first step in that direction so that you can at least add\n> mergeinfo manually.\n\nInteresting. I didn't see this since I'm using the released version.\n\nBut I've been reading the most recent documentation file.\nHow come the documentation wasn't updated?\nIs it intentionally not documented yet?\n\n> But, git-svn.perl is basically in maintenance mode\n> it seems, and more work is being done to implement a new svn remote helper.\n\nIs there already code for this new helper I can look at?\n \n> Also, I think merge tracking wasn't that reliable in svn 1.5 before svn\n> 1.6, and we try to support older versions. In particular, we want to\n> support the versions on typical svn hosting sites which are not always\n> that recent.\n\n\"Not that reliable\" is a pretty fuzzy statement that I cannot really\nprovide a specific answer to.\n\nThere were various implementation bugs in early 1.5 releases causing\nmiscalculations of mergeinfo. Those were client-side problems.\nThe client calculates mergeinfo and uses it to determine which revisions\nto request during a merge. The server only stores mergeinfo and does not\nevaluate it, expect in case of the -g option for \"svn log\" which makes\nrevisions from merged branches show up in the log output (analogous to\nhow individual branch commits are shown in gitk).\n\nSo it shouldn't matter much which version of the server a hosting site\nis running. As long as the server is running some 1.5 release git-svn should,\nin general, be able to cope just fine. Even with a 1.4 server git-svn could\ncommit svn:mergeinfo properties, though other svn clients won't bother using\nthem until the server and repository format is upgraded.\n\nMaybe there was some server-side problem that prevented you from doing\nsomething specific? In general it really shouldn't matter.\n"},{"id":"166081","messageId":"4DAD7EFB.2050507@drmicha.warpmail.net","threadId":"27126","inReplyTo":"20110419120031.GE4134@ted.stsp.name","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-19T12:24:27Z","receivedAt":"2011-04-19T12:24:27Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Stefan Sperling venit, vidit, dixit 19.04.2011 14:00:\n> On Tue, Apr 19, 2011 at 01:19:32PM +0200, Michael J Gruber wrote:\n>> Stefan Sperling venit, vidit, dixit 19.04.2011 11:31:\n>>> On Mon, Apr 18, 2011 at 10:55:18AM -0700, Junio C Hamano wrote:\n>>>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>>>>\n>>>>> Stefan Sperling <stsp@stsp.name> writes:\n>>>>>\n>>>>>> -DESIGN PHILOSOPHY\n>>>>>> ------------------\n>>>>>> -Merge tracking in Subversion is lacking and doing branched development\n>>>>>> -with Subversion can be cumbersome as a result.  While 'git svn' can\n>>>>>> track\n>>>>>\n>>>>> Agreed (this and the rest of the patch). Users reading git-svn's doc\n>>>>> don't want a dissertation about how bad SVN is, and if they do, they can\n>>>>> read whygitisbetterthanx ;-)\n>>>\n>>> Exactly :)\n>>>\n>>> And they might rather want to learn more about how Subversion has improved\n>>> since version 1.4. It seems that these parts of the text were written\n>>> before Subversion's 1.5 release. SVN is a lot more capable now than the\n>>> git-svn docs suggest and I'm surprised that git-svn's development seems\n>>> to have gotten stuck at the 1.4 level of functionality. Not even CentOS\n>>> ships with 1.4 anymore these days.\n>>>\n>>> E.g. git-svn could be taught to generate svn mergeinfo compatible with other\n>>> Subversion clients. It's not easy to come up with a generic mapping between\n>>> the two systems but for some use cases it should be reasonably straightforward.\n>>> This would be a nice improvement towards making git-svn a proper drop-in\n>>> replacement for the standard svn client. Currently, git-svn cannot be\n>>> used without disturbing other users doing merges with Subversion itself\n>>> which is a pity.\n>>\n>> 6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)\n>>\n>> made a first step in that direction so that you can at least add\n>> mergeinfo manually.\n> \n> Interesting. I didn't see this since I'm using the released version.\n> \n> But I've been reading the most recent documentation file.\n> How come the documentation wasn't updated?\n> Is it intentionally not documented yet?\n> \n>> But, git-svn.perl is basically in maintenance mode\n>> it seems, and more work is being done to implement a new svn remote helper.\n> \n> Is there already code for this new helper I can look at?\n\nPlease look for \"svn-fe\".\n\n>  \n>> Also, I think merge tracking wasn't that reliable in svn 1.5 before svn\n>> 1.6, and we try to support older versions. In particular, we want to\n>> support the versions on typical svn hosting sites which are not always\n>> that recent.\n> \n> \"Not that reliable\" is a pretty fuzzy statement that I cannot really\n> provide a specific answer to.\n\n\"I think\" == \"fuzzy\" ;)\n\n> \n> There were various implementation bugs in early 1.5 releases causing\n> miscalculations of mergeinfo. Those were client-side problems.\n> The client calculates mergeinfo and uses it to determine which revisions\n> to request during a merge. The server only stores mergeinfo and does not\n> evaluate it, expect in case of the -g option for \"svn log\" which makes\n> revisions from merged branches show up in the log output (analogous to\n> how individual branch commits are shown in gitk).\n> \n> So it shouldn't matter much which version of the server a hosting site\n> is running. As long as the server is running some 1.5 release git-svn should,\n> in general, be able to cope just fine. Even with a 1.4 server git-svn could\n> commit svn:mergeinfo properties, though other svn clients won't bother using\n> them until the server and repository format is upgraded.\n> \n> Maybe there was some server-side problem that prevented you from doing\n> something specific? In general it really shouldn't matter.\n\nWell, it's helpful to know all the above!\n\n--\"mergeinfo\" is halfway implemented in the sense that \"git-svn\" neither\nhelps you give that information properly (it could try to find the\nrevision range and knows the branch) nor does it use it. Also, git-svn\nseems to be inconsistent in its use of \"--long opt\" and \"--long=opt\".\nAnyways, here's a documentation patch. (I'm trying out my newly acquired\nknowledge from SubmittingPatches rather then send-email, so hopefully\nthis is not fl[ao]wed.)\n\n--- >8 ---\nFrom: Michael J Gruber <git@drmicha.warpmail.net>\nSubject: [PATCH] git-svn.txt: Document --mergeinfo\n\n6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)\nintroduced the --mergeinfo option. Document it.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/git-svn.txt |    7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex ea8fafd..96ac46b 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -217,6 +217,13 @@ config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)\n Using this option for any other purpose (don't ask) is very strongly\n discouraged.\n \n+--mergeinfo=<mergeinfo>;;\n+\tAdd the given merge information during the dcommit\n+\t(e.g. `--mergeinfo=\"/branches/foo:1-10\"`). All svn server versions can\n+\tstore this information (as a property), and svn clients starting from\n+\tversion 1.5 can make use of it. 'git svn' currently does not use it\n+\tand does not set it automatically.\n+\n 'branch'::\n \tCreate a branch in the SVN repository.\n \n-- \n1.7.5.rc1.312.g1936c\n"},{"id":"166086","messageId":"BANLkTimJa5EDxXerwgZP7viLFPQRc=39uQ@mail.gmail.com","threadId":"27126","inReplyTo":"4DAD7EFB.2050507@drmicha.warpmail.net","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-04-19T15:59:54Z","receivedAt":"2011-04-19T15:59:54Z","isPatch":true,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Tue, Apr 19, 2011 at 2:24 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Stefan Sperling venit, vidit, dixit 19.04.2011 14:00:\n>> On Tue, Apr 19, 2011 at 01:19:32PM +0200, Michael J Gruber wrote:\n>>> But, git-svn.perl is basically in maintenance mode\n>>> it seems, and more work is being done to implement a new svn remote helper.\n>>\n>> Is there already code for this new helper I can look at?\n>\n> Please look for \"svn-fe\".\n\nsvn-fe is a one-time conversion tool, isn't it? It's completely\ndifferent than git-svn,\nwhich allows interactive working with existing svn repository.\n\nBTW, sorry for hijacking the thread, but could someone with better knowledge of\ngit-svn look at this problem:\n    http://thread.gmane.org/gmane.comp.version-control.git/171481\n\nThanks,\n\n-- \nPiotr Krukowiecki\n"},{"id":"166660","messageId":"20110428173416.GC15785@ted.stsp.name","threadId":"27126","inReplyTo":"20110419093108.GA7440@ted.stsp.name","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-28T17:34:16Z","receivedAt":"2011-04-28T17:34:16Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"On Tue, Apr 19, 2011 at 11:31:08AM +0200, Stefan Sperling wrote:\n> I've sent a signed-off version with git send-email. Thanks!\n\nPing.  Apparently this hasn't been committed yet.\n"},{"id":"166662","messageId":"4DB9AA88.8040505@elegosoft.com","threadId":"27126","inReplyTo":"20110428173416.GC15785@ted.stsp.name","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Michael Schubert","fromEmail":"mschub@elegosoft.com","sentAt":"2011-04-28T17:57:28Z","receivedAt":"2011-04-28T17:57:28Z","isPatch":true,"sender":{"key":"mschub@elegosoft.com","avatar":null},"body":">> I've sent a signed-off version with git send-email. Thanks!\n> \n> Ping.  Apparently this hasn't been committed yet.\n\nIt's queued in next:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/172274\n"},{"id":"166728","messageId":"20110429103953.GA4315@ted.stsp.name","threadId":"27126","inReplyTo":"4DB9AA88.8040505@elegosoft.com","subject":"Re: [PATCH] remove noise and inaccuracies from git-svn docs","fromName":"Stefan Sperling","fromEmail":"stsp@stsp.name","sentAt":"2011-04-29T10:39:53Z","receivedAt":"2011-04-29T10:39:53Z","isPatch":true,"sender":{"key":"stsp@elego.de","avatar":"https://avatars.githubusercontent.com/u/9281333?v=4"},"body":"On Thu, Apr 28, 2011 at 07:57:28PM +0200, Michael Schubert wrote:\n> >> I've sent a signed-off version with git send-email. Thanks!\n> > \n> > Ping.  Apparently this hasn't been committed yet.\n> \n> It's queued in next:\n> \n> http://article.gmane.org/gmane.comp.version-control.git/172274\n\nAh, nice :)  Thanks everyone!\n"},{"id":"167160","messageId":"loom.20110505T211005-593@post.gmane.org","threadId":"27126","inReplyTo":"BANLkTimJa5EDxXerwgZP7viLFPQRc=39uQ@mail.gmail.com","subject":"git-svn and a new svn remote helper","fromName":"Matthew L Daniel","fromEmail":"mdaniel@gmail.com","sentAt":"2011-05-05T19:13:04Z","receivedAt":"2011-05-05T19:13:04Z","isPatch":false,"sender":{"key":"mdaniel@gmail.com","avatar":"https://gravatar.com/avatar/0a9033d5df2e8bf6bf26b1a5c57cbd5fcc467311a673a7e8945f90acc3b620df?d=mp&s=160"},"body":"> >> On Tue, Apr 19, 2011 at 01:19:32PM +0200, Michael J Gruber wrote:\n> >>> But, git-svn.perl is basically in maintenance mode\n> >>> it seems, and more work is being done to implement a new svn remote helper.\n> >>\n> >> Is there already code for this new helper I can look at?\n> >\n> > Please look for \"svn-fe\".\n> \n> svn-fe is a one-time conversion tool, isn't it? It's completely\n> different than git-svn,\n> which allows interactive working with existing svn repository.\n\nThe original thread appears to have died, but I am curious about its outcome.\n\nIs there, in fact, a new svn remote helper under development?\n\n  Thanks kindly,\n  -- /v\\atthew\n"},{"id":"167181","messageId":"BANLkTikAtgunYTax5d4oEDAot83wOROmhw@mail.gmail.com","threadId":"27126","inReplyTo":"loom.20110505T211005-593@post.gmane.org","subject":"Re: git-svn and a new svn remote helper","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-05-05T20:25:06Z","receivedAt":"2011-05-05T20:25:06Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, May 5, 2011 at 21:13, Matthew L Daniel <mdaniel@gmail.com> wrote:\n> Is there, in fact, a new svn remote helper under development?\n\nYes, Dmitry Ivankov is working on this as part of his GSoC project [0].\n\n[0] http://www.google-melange.com/gsoc/project/google/gsoc2011/divanorama/17001\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"167184","messageId":"BANLkTimZ6P=b6KHnj2+re5zke4Ds1012Eg@mail.gmail.com","threadId":"27126","inReplyTo":"BANLkTikAtgunYTax5d4oEDAot83wOROmhw@mail.gmail.com","subject":"Re: git-svn and a new svn remote helper","fromName":"Matthew Daniel","fromEmail":"mdaniel@gmail.com","sentAt":"2011-05-05T20:32:05Z","receivedAt":"2011-05-05T20:32:05Z","isPatch":false,"sender":{"key":"mdaniel@gmail.com","avatar":"https://gravatar.com/avatar/0a9033d5df2e8bf6bf26b1a5c57cbd5fcc467311a673a7e8945f90acc3b620df?d=mp&s=160"},"body":"On Thu, May 5, 2011 at 10:25 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> On Thu, May 5, 2011 at 21:13, Matthew L Daniel <mdaniel@gmail.com> wrote:\n>> Is there, in fact, a new svn remote helper under development?\n>\n> Yes, Dmitry Ivankov is working on this as part of his GSoC project [0].\n>\n> [0] http://www.google-melange.com/gsoc/project/google/gsoc2011/divanorama/17001\n\nThe link wasn't very informative; is this work scheduled to happen in\npublic, e.g. on a git branch perhaps?\n\nHas Dmitry submitted the GSoC design document yet?\n\nInquiring minds want to know. :-)\n\n  Thanks for your help,\n  -- /v\\atthew\n"},{"id":"167185","messageId":"BANLkTi=-awfPDNivaKT3EkC638_U2cQtRA@mail.gmail.com","threadId":"27126","inReplyTo":"BANLkTimZ6P=b6KHnj2+re5zke4Ds1012Eg@mail.gmail.com","subject":"Re: git-svn and a new svn remote helper","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-05-05T20:33:19Z","receivedAt":"2011-05-05T20:33:19Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, May 5, 2011 at 22:32, Matthew Daniel <mdaniel@gmail.com> wrote:\n> The link wasn't very informative; is this work scheduled to happen in\n> public, e.g. on a git branch perhaps?\n\nHopefully he will update his project information soon :).\n\n> Has Dmitry submitted the GSoC design document yet?\n\nNo, I haven't seen him on the list yet.\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}