Re: [PATCH] remove noise and inaccuracies from git-svn docs

[Michael J Gruber <git@drmicha.warpmail.net>]

Stefan Sperling venit, vidit, dixit 19.04.2011 14:00:
> On Tue, Apr 19, 2011 at 01:19:32PM +0200, Michael J Gruber wrote:
>> Stefan Sperling venit, vidit, dixit 19.04.2011 11:31:
>>> On Mon, Apr 18, 2011 at 10:55:18AM -0700, Junio C Hamano wrote:
>>>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>>>
>>>>> Stefan Sperling <stsp@stsp.name> writes:
>>>>>
>>>>>> -DESIGN PHILOSOPHY
>>>>>> ------------------
>>>>>> -Merge tracking in Subversion is lacking and doing branched development
>>>>>> -with Subversion can be cumbersome as a result.  While 'git svn' can
>>>>>> track
>>>>>
>>>>> Agreed (this and the rest of the patch). Users reading git-svn's doc
>>>>> don't want a dissertation about how bad SVN is, and if they do, they can
>>>>> read whygitisbetterthanx ;-)
>>>
>>> Exactly :)
>>>
>>> And they might rather want to learn more about how Subversion has improved
>>> since version 1.4. It seems that these parts of the text were written
>>> before Subversion's 1.5 release. SVN is a lot more capable now than the
>>> git-svn docs suggest and I'm surprised that git-svn's development seems
>>> to have gotten stuck at the 1.4 level of functionality. Not even CentOS
>>> ships with 1.4 anymore these days.
>>>
>>> E.g. git-svn could be taught to generate svn mergeinfo compatible with other
>>> Subversion clients. It's not easy to come up with a generic mapping between
>>> the two systems but for some use cases it should be reasonably straightforward.
>>> This would be a nice improvement towards making git-svn a proper drop-in
>>> replacement for the standard svn client. Currently, git-svn cannot be
>>> used without disturbing other users doing merges with Subversion itself
>>> which is a pity.
>>
>> 6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)
>>
>> made a first step in that direction so that you can at least add
>> mergeinfo manually.
> 
> Interesting. I didn't see this since I'm using the released version.
> 
> But I've been reading the most recent documentation file.
> How come the documentation wasn't updated?
> Is it intentionally not documented yet?
> 
>> But, git-svn.perl is basically in maintenance mode
>> it seems, and more work is being done to implement a new svn remote helper.
> 
> Is there already code for this new helper I can look at?

Please look for "svn-fe".

>  
>> Also, I think merge tracking wasn't that reliable in svn 1.5 before svn
>> 1.6, and we try to support older versions. In particular, we want to
>> support the versions on typical svn hosting sites which are not always
>> that recent.
> 
> "Not that reliable" is a pretty fuzzy statement that I cannot really
> provide a specific answer to.

"I think" == "fuzzy" ;)

> 
> There were various implementation bugs in early 1.5 releases causing
> miscalculations of mergeinfo. Those were client-side problems.
> The client calculates mergeinfo and uses it to determine which revisions
> to request during a merge. The server only stores mergeinfo and does not
> evaluate it, expect in case of the -g option for "svn log" which makes
> revisions from merged branches show up in the log output (analogous to
> how individual branch commits are shown in gitk).
> 
> So it shouldn't matter much which version of the server a hosting site
> is running. As long as the server is running some 1.5 release git-svn should,
> in general, be able to cope just fine. Even with a 1.4 server git-svn could
> commit svn:mergeinfo properties, though other svn clients won't bother using
> them until the server and repository format is upgraded.
> 
> Maybe there was some server-side problem that prevented you from doing
> something specific? In general it really shouldn't matter.

Well, it's helpful to know all the above!

--"mergeinfo" is halfway implemented in the sense that "git-svn" neither
helps you give that information properly (it could try to find the
revision range and knows the branch) nor does it use it. Also, git-svn
seems to be inconsistent in its use of "--long opt" and "--long=opt".
Anyways, here's a documentation patch. (I'm trying out my newly acquired
knowledge from SubmittingPatches rather then send-email, so hopefully
this is not fl[ao]wed.)

--- >8 ---
From: Michael J Gruber <git@drmicha.warpmail.net>
Subject: [PATCH] git-svn.txt: Document --mergeinfo

6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)
introduced the --mergeinfo option. Document it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-svn.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ea8fafd..96ac46b 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -217,6 +217,13 @@ config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)
 Using this option for any other purpose (don't ask) is very strongly
 discouraged.
 
+--mergeinfo=<mergeinfo>;;
+	Add the given merge information during the dcommit
+	(e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can
+	store this information (as a property), and svn clients starting from
+	version 1.5 can make use of it. 'git svn' currently does not use it
+	and does not set it automatically.
+
 'branch'::
 	Create a branch in the SVN repository.
 
-- 
1.7.5.rc1.312.g1936c