[Mono-dev] The new world of Git -- what else can we change :-)
Miguel de Icaza
miguel at novell.com
Wed Jul 28 10:52:59 EDT 2010
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list