Re: Switching from CVS to GIT
- From
Andreas Ericsson <ae@op5.se>
- Date
- Oct 14, 2007, 23:55 UTC
- Message-ID
- <4712AC8C.9050006@op5.se>
- In-Reply-To
- <u7ilpjp3x.fsf@gnu.org>
Eli Zaretskii wrote:
Show 12 quoted lines
>> Date: Mon, 15 Oct 2007 00:14:46 +0200 >> From: Alex Riesen <raa.lkml@gmail.com> >> Cc: Andreas Ericsson <ae@op5.se>, Benoit SIGOURE <tsuna@lrde.epita.fr>, >> git list <git@vger.kernel.org>, Eli Zaretskii <eliz@gnu.org>, >> Make Windows <make-w32@gnu.org> >> >> Re "functional". Have to remind something (besides the fork): > > That's a 20-20 hindsight: if you deliberately write a program to rely > heavily on Posix-isms, don't be surprised when you discover that it > cannot be easily ported to other platforms. >
True. It was originally developed because Linux kernel development came to a stand-still and needed an scm quickly. Since the original design worked out nicely, nobody bothered (then) about possible future porting issues. Windows is still a second class citizen, but that's true for pretty much every unix-born application out there, so I'm not all that stressed out about it.
Show 8 quoted lines
> >> - no proper filename semantics (case-insensitivity and stupid rules for >> allowed characters in filenames, like ":" in filenames in >> cross-platform projects) > > There's a flag on Windows to open files case-sensitively, if you need > that. In any case, I don't see how this can be of any real relevance > to porting GIT.
Because having
Path/foo path/Foo PATH path/foo
is possible in git's native playground, but not on windows, so it can quite seriously hamper cross-platform cooperation. When that happens, users usually start blaming the tools in use. Browse the list archives for HFS and you'll see what I mean, although come to think of it, the HFS problems might actually be worse, since HFS reports case-changes while not actually being case-sensitive.
> As for ":" in file names, simply don't use it, like > you don't use white space or characters below 32 decimal: it's > inconvenient, even if it's allowed. >
It's still a real problem because sooner or later someone will use that, and it needs to be handled with a bit more grace than just bombing out.
Show 5 quoted lines
> >> - no real "mmap" (which kills perfomance and complicates code) > > You only need mmap because you are accustomed to use it on GNU/Linux. >
Not really. mmap() provides a real performance boost when reading large repos, due to the sliding window code that handles pack-files. mmap was invented for occasions like that, and was allowed to endure because it was a much better solution than simply read(fd, buf, st.st_size) and moving pointers around.
Show 12 quoted lines
>> Interprocess communication: >> >> - no reliable text environment (I'm programming in the damn thing for >> 10 years and I still don't know how to pass an environment variable >> _for_sure_) >> >> - it has only one argument (limited in size) passed to started >> programs, which means that there is no possible way to safely pass >> file and text arguments on command line (more than one, that is) > > Not enough context, so I cannot talk intelligently about this. Why do > you need interprocess communication in the first place?
Because some of the commands operate on large data-sets that are best passed as a stream. It's ridiculously easy to set that up on unix, but (afaiu) quite troublesome under windows.
> why not simply > give birth to a subsidiary process and pass it a command line (which > can be up to 32KB)?
I believe work is in progress that will run things as threads rather than using fork()+execve(). 32KiB of data is nowhere near enough to sustain many of the more data-hungry commands. Or rather, it won't be once the repository has grown passed 50-odd revisions.
All that being said, welcome to the git mailing list. Hopefully you can help iron out the wrinkles on windows. You seem to have a fairly good grasp of what's available there, and I'm sure the msys team would be pretty happy to get a few patches to speed them on their way.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231