Re: [Fwd: Re: What's in git.git]

Re: [Fwd: Re: What's in git.git]

[Jon Smirl]

On 11/19/06, Shawn Pearce <spearce@spearce.org> wrote:
> Have you been watching the shallow clone threads?

Some friends of mine are doing a start up that is sort of like a Sonos
system but with some major differences. I've been helping them out so
I've been doing chip design and PCB layouts lately. The system also
needs some really complicated real-time, wireless mesh routing
software, I wish the OLPC 802.11s code was ready.

Brendan told me that he would not consider Mozilla moving to git until
a native Windows version is released so I just dropped the whole
thing. It is too much effort and they don't even really want it. They
are probably going to switch to SVN.  I told him that SVN would end up
being a disaster and he got mad at me. That's when I stopped working
on cvs2svn/git.

The shallow clone work is being done in the wrong order to get the
Mozilla people interested.
#1) There needs to be a tool that can accurately import the
repository. cvs2svn does not do this. The good programmers working on
git could probably whip this out in a week or two if they wanted to.
cvs2svn is very close but they refuse to solve the symbol dependency
problem.
#2) git needs native Windows support, this probably includes MSVC
integration. There are a lot of non-technical people working on
Mozilla like accessibility, doc, artwork, translations, they are all
on Windows. Brendan explicitly ruled out cygwIn.
#3) Once #1 and #2 are achieved then they will care about shallow clone.

The only way I can see Mozilla moving to git is if the git community
ports the repository for them and then demonstrates that all of the
needed tools and available and working.

> ---------- Forwarded message ----------
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> To: Junio C Hamano <junkio@cox.net>
> Date: Sun, 19 Nov 2006 16:17:17 +0100 (CET)
> Subject: Re: What's in git.git
> Hi,
>
> On Sat, 18 Nov 2006, Junio C Hamano wrote:
>
> > Junio C Hamano <junkio@cox.net> writes:
> >
> > >  - 'pu' has the shallow clone WIP and a half-finished rewrite of
> > >    git branch in C, both by Johannes.  Both needs a bit more
> > >    polishing and confidence building before going into 'next',
> > >    and given the recent discussion of enhancing branch
> > >    management for pulls/pushes, it might be easier to drop the
> > >    latter for now.
> >
> > OOPS; sorry but the latter half is entirely untrue.  What's
> > there is half-done git-shortlog.  Scratch everything about
> > branch management please.
>
> IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out
> the built-in mailmap which is totally specific to the Linux kernel
> development.
>
> As for shallow clone support: I am a bit underwhelmed by the enthusiasm
> to test this thing by the people I thought would be most interested. It
> really could be the case that it is not needed at all.
>
> Just for the record, though: AFAICT the shallow stuff is lacking support
> for at least pushing from/into shallow repos and it should avoid making a
> commit shallow unnecessarily. And quite likely there are a few thinkos in
> it, so it would not hurt having more test cases (notably of things I did
> not think of), and some bad-ass testing with huge amounts of commits and
> files which were added/modified identically in different commits.
>
> Ciao,
> Dscho
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>


-- 
Jon Smirl

Re: [Fwd: Re: What's in git.git]

[Petr Baudis]

On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> Brendan told me that he would not consider Mozilla moving to git until
> a native Windows version is released so I just dropped the whole
> thing. It is too much effort and they don't even really want it. They
> are probably going to switch to SVN.  I told him that SVN would end up
> being a disaster and he got mad at me. That's when I stopped working
> on cvs2svn/git.

I see. :-(

Could you please publish cvs2git in whatever state you have it so that
someone else possibly interested could pick it up and finish the missing
bits? It would be shame if the already done work would end up wasted.

> #2) git needs native Windows support, this probably includes MSVC
> integration. There are a lot of non-technical people working on
> Mozilla like accessibility, doc, artwork, translations, they are all
> on Windows. Brendan explicitly ruled out cygwIn.

This is sort of catch-22, we have probably no developers interested
enough in porting Git to native Windows and it's not clear we are going
to get any until Git runs on native Windows.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."

Re: [Fwd: Re: What's in git.git]

[Robin Rosenberg]

söndag 19 november 2006 18:49 skrev Petr Baudis:
> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> > Brendan told me that he would not consider Mozilla moving to git until
> > a native Windows version is released so I just dropped the whole
> > thing. It is too much effort and they don't even really want it. They
> > are probably going to switch to SVN.  I told him that SVN would end up
> > being a disaster and he got mad at me. That's when I stopped working
> > on cvs2svn/git.
>
> I see. :-(
>
> Could you please publish cvs2git in whatever state you have it so that
> someone else possibly interested could pick it up and finish the missing
> bits? It would be shame if the already done work would end up wasted.
>
> > #2) git needs native Windows support, this probably includes MSVC
> > integration. There are a lot of non-technical people working on
> > Mozilla like accessibility, doc, artwork, translations, they are all
> > on Windows. Brendan explicitly ruled out cygwIn.
>
> This is sort of catch-22, we have probably no developers interested
> enough in porting Git to native Windows and it's not clear we are going
> to get any until Git runs on native Windows.

Having a usable set of git in C-format (or C++) is what it takes to get things 
rolling. Make the shores of Git-land shallow with nice beaches, so it easy to 
enter and you'll get people there, just out of curiosity. They'll start 
improving things after a while.

Even if it is possible to run bash, python, perl and who-knows-what in native 
windows it makes installing and packaging complicated. It is quite simple to 
install git under cygwin for people versed in cygwin or Linux, but not for 
those that have no interest in those two.

As for plugins to visual studio and othe strange things, they will come if a 
practically usable core set is in place, that can be built and redestributed 
without a ton of dependencies. People have used visual studio with CVS and 
other tools without plugins for a long time just fine so Git will do fine 
withour it for a while too. Eventually we'll have TortoiseGit. They key is a 
usable subset of Git that only requires a C compiler (or C++). Other 
solutions are ofcourse possible (like a C# re-implementation), but making 
things native C-code is the most straightforward path that doesn't split the 
code base.

Re: [Fwd: Re: What's in git.git]

[Jon Smirl]

On 11/19/06, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:
> > Brendan told me that he would not consider Mozilla moving to git until
> > a native Windows version is released so I just dropped the whole
> > thing. It is too much effort and they don't even really want it. They
> > are probably going to switch to SVN.  I told him that SVN would end up
> > being a disaster and he got mad at me. That's when I stopped working
> > on cvs2svn/git.
>
> I see. :-(
>
> Could you please publish cvs2git in whatever state you have it so that
> someone else possibly interested could pick it up and finish the missing
> bits? It would be shame if the already done work would end up wasted.

Working on cvs2git is the wrong direction. cvs2svn has been
specifically tuned for importing into SVN and they aren't interested
in making the architectural changes that git needs.

There is a core problem in the way cvs2svn handles CVS symbols.

> I posted a three commit example of the problem.
>
> FileA has rev 1.1 and rev 1.2
> FileB has rev 1.1
> A symbol is created between A 1.1/1.2 and after B 1.1
>
> cvs2svn generated two change sets
> 1) FileA 1.1
> 2) FileB 1.1, FileA 1.2
>
> With these two change sets it is impossible to base the symbol simply,
> there is no solution without copying. cvs2svn generates the symbol
> based on #1 and copies FileB 1.1 from #2.
>
> The alternative is to output three change sets which is also a valid
> representation of the same data.
> 1) FileA 1.1
> 2) FileB 1.1
> 3) FileA 1.2
>
> Now there is a solution for the symbol, base is on change set #2. No
> copies needed.
>
> By introducing symbol dependencies (which cvs2svn does not do) you can
> force the second change set sequence to be generated.

SVN allows a label to be made by picking a commit from six months ago
with 80% of the right files in it. They then link to revisions from
later commits to build up the file set needed for the label. Doing it
this way turns every symbol into a little branch. It is fixing the
symptoms rather than fixing the problem of figuring out the correct
construction of the change sets. The SVN people seem to be perfectly
happy with these little branches and they aren't going to change
cvs2svn.

cvs2svn is a nice piece of code and a good thing to look at for
reference. It includes some excellent test cases. The author is a
Python expert and uses every last feature of the language which makes
to code hard to understand at times. He also loves to refactor things
and does so continuously. This is a major problem for any long lived
patches. If you do choose to work on cvs2svn, just fork it until you
are done developing, don't try to track the refactorings.

There are several other choices. Monotone is getting a pretty good
importer and the author is aware of the problem described above and is
writing his code to avoid it. Monotone is in C++ and make heavy use of
the Boost C++ template library. Because of this I can't tell what
their code does, it doesn't look like C++ anymore.

git is in C and has high code quality standards. I would just start
from scratch and write the importer over while referencing the
existing code. If anyone is interested in doing this I will be happy
to explain what I know about doing the import accurately and quickly.
With the right algorithms it is possible to import Mozilla CVS with
2GB memory in under an hour on a desktop machine.

Shawn has written git-fastimport. fastimport takes an input stream of
a simple language and then creates the git repository. The CVS
importer just needs to generate these commands.

With the current knowledge of issues around doing CVS import this
problem is not as hard as it used to be. Dozens of attempts have been
made at this problem, Shawn and I have looked at all of these and know
where the algorithmic mistakes are. The only big outstanding problem I
know of with import is the issue described above which no one has
coded a solution for yet.

Once a solution has been found for this problem the next problem is
detecting when a branch gets merged back into the trunk. After that I
think the problem is fully solved.

-- 
Jon Smirl