Re: Improving git-svn documentation

> While diving into the git-svn code, I realized that many things could
> be done to make it more documented/understundable.  I need to get more
> understanding of it, so I'd like to improve this state of things.  But
> first, I'd like to be sure there is a consensus on what is a good idea
> to do, since that could easily turn up into a lot of textual change.
> 
> - (on the user doc side of things) some options appear not to be
>   documented (I spotted --parent for 'clone' and --revision for
>   'dcommit').  But looking at where to document them, I found it not
>   always easy, since some options are documented together with the
>   command they modify, some others in the "options" section (even when
>   they are documented as applying to a single command, like --shared
>   or --stdin).  This IMHO leads to confusion for the user looking for
>   information, as well as to the reviewer trying to check that nothing
>   was forgotten.  I would rather make that only very commons are
>   described in a common "options" section, and that all commands using
>   them explicitely say so in their descriptions (with xref).

> - (on the code side of things) git-svn.perl weights more than 5500
>   lines, most classes functions and methods severely lack
>   documentation, and some extensively-used variable names are so short
>   they make the code harder to grasp
> 
>   Eg. $gs to refer to an instance of the Git::SVN class, which I would
>   suggest to change to something like $gsrepo, while at the same time
>   renaming Git::SVN to eg. Git::SVN::Repository - which would make it
>   much easier for a newcomer to grasp what this is supposed to
>   represent - supposing, that is, that my understunding of this part
>   is accurate enough, which it is probably not after spending many
>   hours in there :)

>   As to the size of the file, it seems natural to me to split the
>   classes into their own files.  That would still let git-svn.perl and
>   the Git::SVN class to be 1500-lines tall, the largest others
>   achieving around 500 lines.  That should be much more manageable
>   pieces, and would require some refactoring wrt a couple of global
>   variables used throughout the script; which, incidentally, could
>   make it much easier to simultanously look at several git-svn
>   repositories (for my work on mapping externals to submodules), and
>   to allow reusing the existing code, eg. as a git-vcs backend.
> 
> How are you people feeling about this rough plans ?