[rfc] Windows symlink support

[Stuart Jansen]

On Fri, 2006-01-13 at 19:55 -0500, John Yates wrote:
> Applying such an approach to bzr by default I would reject
> 
>  - symlinks and multiple hard links
>  - names that collide under case folding and/or Unicode
>    canonicalization
>  - anything else that violates the common intersection of
>    the various file systems that I would hope to support
> 
> I would then create a means of relaxing those defaults via
> project policies.  Thus one could record within a project
> that it is okay to add symlinks as versioned objects.  But
> a freshly minted project would not come into existence with
> that capability.  You would have to actively and consciously
> enable it.

I agree with disabling functionality with security implications and
allowing users to relax policy by enabling it. I wonder if there might
be some for case folding/Unicode canonicalization. 

In general, however, I would approach from the opposite direction.
Functionality should be enabled by default, but users user should be
educated and allowed to define their own policy by explicitly disabling
certain features.

> Ultimately I think that I am not precluding the functionality
> that you desire.  But I am a very strong proponent of the
> principle of least astonishment.  And perhaps I may be
> more willing than you to advocate trading off ease of use in
> the system management / backup use case so as to make bzr a
> better, less error-prone tool for distributed software
> development across disparate platforms.

I use only Linux. Frankly, I would be quite astonished by any modern RCS
that didn't support symlinks by default. I suspect that educating the
user is a better course. How about the following approach:

1) Users are allowed to commit symlinks by default. Any time a symlink
is modified and commited, near the end of the commit output the user is
informed that symlinks are not portable and may cause problems on other
platforms. The user is further informed that this warning can be
disabled by changing a setting in the user's global configuration. 

The setting should be per-user and not per-project because the purpose
of the warning is user education. Disabling the verbose warning causes
it to be replaced by a one line warning essentially stating "Project
contains symlinks." Both the verbose and the one-line warning should be
near the end of the commit output because it is less likely to be missed
or ignored.

2) Similarly, on filesystems that do not support symlinks, bzr should
not prevent the check out and should preserve the links. Again the user
should be educated about the presence and implications of the links and
how to suppress the verbose message in the future if desired.

3) On a per-project basis, it should be possible to specify that
symlinks are not allowed in the project. This allows maintainers who are
concerned about portability to easily enforce a policy.

4) Hard links would be nice but are probably best left to bzr 2.0 if
users actually request them.

Concerns: My understanding is that bzr is trying to avoid an explosion
of configuration options. I also wonder how this will affect scripting
of bzr as well as alternative interfaces other than the command line.

-- 
Stuart Jansen <sjansen at gurulabs.com>
Guru Labs, L.C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060114/3c5210d9/attachment.pgp