Re: Cross-Platform Version Control

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 29 April 2009, Martin Langhoff wrote:
> On Tue, Apr 28, 2009 at 1:24 PM, Jakub Narebski <jnareb@gmail.com>
> wrote: 

[I think you cut out a bit too much. Here I resurrected it]

JN> 1. Different limitations on file names (e.g. pathname length),
JN>   different special characters, different special filenames
JN>   (if any).
[...]
JN>   The answer is convention for filenames in a project. Simply
JN>   DON'T use filenames which can cause problems.
[...]

> >   DON'T DO THAT.

What could be proper solution to that, if you do not accept social 
rather than technical restriction?  We can have pre-commit hook that 
checks for portability for filenames (which is deployment specific,
and shouldn't be part of SCM perhaps with an exception of being example 
hook) but it wouldn't help dealing with non-portable filenames on 
filesystem that cannot represent them that are there.

If I remember correctly Git for some time has layer which can translate 
between filenames in repository and filenames on filesystem, but I'm 
not sure if it is generic enough for it to be a solution to this 
problem, and currently there is no way to manipulate this mapping, I 
think.


JN> 2. "Case-insensitive" but "case-preserving" filesystems. [...]
JN>
JN>     The answer is like for previous issue: don't.  Simply DO NOT
JN>     create files with filenames which differ only in case [...]

> >   DON'T DO THAT, SOLVABLE.

By 'solvable' here I mean that you should be able to modify only one of 
clashing files at once (checkout 'README', modify, add to index, remove 
from filesystem, checkout 'readme', modify, etc.), and deal with 
annoyances in git-status output.  It can be done in Git, with medium 
amount of hacking.  I don't think any other SCM can do even this, and
I cannot think of a better, automatic solution that would somehow deal 
with case-clashing.

Note that all deals are off in case-insensitive and not preserving 
filesystem.

By the way, wouldn't be a better solution to use sane filesystem, rather 
than complicating SCM? ;-)

> 
> As I mentioned, Eric is taking the perspective of offering a supported
> SCM to a large and diverse audience. As such, his notes are
> interesting not because he's right or he's wrong.
> 
> We can be "right" and say "don't do that" if we shrink our audience so
> that it looks a lot like us. There, fixed.

<quote source="Dune by Frank Herbert">
  [...] the attitude of the knife — chopping off what's incomplete and
  saying: "Now it's complete because it's ended here."
</quote>

I could not resist posting this quote :-P

> 
> But something tells me that successful tools are -- by definition --
> tools that grow past their creators use.
> 
> So from Eric's perspective, it is worthwhile to work on all those
> issues, and get the right for the end user -- support things we don't
> like, offer foolproof catches and warnings that prevent the user from
> shooting their lovely toes off to mars, etc.

Warnings and catches I can accept; adding complications and corner cases 
for situations which can be trivially avoided with a bit of social 
engineering aka. project guidelines... not so much.

I simply cannot see the situation where you _must_ have dangerously 
unportable file names (trailing dot, trailing whitespace) and 
case-clashing files...

> 
> His perspective is one of commercial licensing, but even if we aren't
> driven by the "each new user is a new dollar" bit, the long term hopes
> for git might also be to be widely used and to improve the version
> control life of many unsuspecting users.
> 
> To get there, I suspect we have to understand more of Eric's
> perspective. 
> 
> that's my 2c.

By the way, I think that the article on cross-platform version control 
(version control in heterogenic environment) is quite good article.
I don't quite like the "10 Issues"/"Top 10" way of writing, but the 
article examines different ways that heterogenic environment can trip 
SCM.  

In my opinion Git does quite good here, where it can, and where the 
issue is to be solved by SCM and not otherwise (extra metadata like 
resource fork).

-- 
Jakub Narebski
Poland