Windows people: please help check idea for a new Mercurial repository layout

[Adrian Buehlmann]

On 14.06.2008 13:22, Paul Moore wrote:
> 2008/6/14 Adrian Buehlmann <adrian at cadifra.com>:
>> So, a simple file/directory encoding strategy (for a new Mercurial repo
>> layout) would be to prepend a period to every directory- and filename
>> inside the .hg dir.
>>
>> If anyone knows this encoding doesn't work, please tell me!
> 
> I see no reason why this would not work. However, it may be a bit more
> wide-ranging than is needed.

Could you define "wide-ranging" and its negative implications?
This would be a new repository format anyway. In that context
the term "wide-ranging" has no meaning for me. Either I change
the repository format or I don't. You can't get a little bit pregnant.

>> Of course this would be a new, incompatible repository layout, so old
>> Mercurial versions would not be able to read such new repositories
>> (see http://www.selenic.com/mercurial/wiki/index.cgi/CompatibilityRules).
> 
> Would it be better to *only* encode repository entries which are
> currently invalid? Say, by tilde-escaping the first letter of the
> special filename (so aux would become ~61ux). Unfortunately,
> util._buildencodefun uses a hard-coded list of translations, so it's
> still backward-incompatible, but at least the majority of repos remain
> compatible.

The code base would be much more stable and simpler if we wouldn't have to
scan for a list of reserved filenames and do some arbitrary encoding on them.

I also fail to see the benefit of "majority of repos remain compatible".
Your proposed encoding is a new repository format as well, because
old Mercurial's can't read your new encoding.

CompatibilityRules requires: "Old Mercurial should break with a
meaningful error message if it can't read a new Mercurial repository".
Meaningful error message for me is "abort: unknown repository format".

Also, a "new repository" should be a stable concept: a non-empty repository
should not mutate from an old one to an new one due to a pull of a changeset.
Such a mutation should only happen on explicit conversion.