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

> 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?

>  
>> 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.

> 
> 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.