[Mono-dev] The new world of Git -- what else can we change :-)

[Miguel de Icaza]

>
> The source trees at github.com/mono/ have a lot of junk^W branches left
> over from the SVN days.  However, we mostly work on two or three main
> branches.  For instance, in the mono/ tree, we work on the unstable
> "master", the stable "mono-2-6" and very occassionally on "mono-2-4".
> So, looking at the 111 branches in the mono/ tree is annoying.  At first
> blush, I guess its pleasing from an code archeology standpoint, and
> pleasing in the sense of a job well done with the SVN import.  But, 111
> branches are distracting to work with -- they are a cognitive overload,
> interfere with command-line completion, and are terrible on the Github
> UI.
>

In general I like the idea of cleaning this up a little bit, perhaps the
idea of tags that was brought up on the list would allow us to keep the
history in some form, while keeping branches useful.

* Real release branches, these have value in that we can determine what we
shipped when.   The older the release, the lesser the value.
* Work branches for code that was eventually merged: I could not find a
single branch of these that was worth keeping around (C5, SAVANNAH_CVS,
NUNIT, XIMIAN, anonymous-methods*, atsushi*, dick*, jb*, martin*,
messaging*, mwf*, post*, sports-model, vargaz*)
* Customer or specific port branches (mainsoft*, wii)

It seems that there is value in making a "historic-mono" for those that are
interested in that history, with a copy of the current repo/branches as-is,
and a big fat warning explaining what the purpose of it is.   We could then
at least delete the work branches and personal branches.

I do not understand tagging, but if that is a real solution, we could use
that for the pre-Mono 2.4 releases, as well as the old Moonlight branch
releases.

Miguel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100728/3fffb446/attachment.html