[rfc] Windows symlink support

[James Blackwell]

On Fri, Jan 13, 2006 at 07:55:57PM -0500, John Yates wrote:
> James,
> 
> I think that there are two very different uses for revision
> control.  Both your comments and those of Wouter van Heyst
> conflate versioning of directories for system management or
> backup with the needs of distributed software development.

The example I had in mind was symlinks that are used in the gnu automake
systems. Things such as INSTALL are often symlinked off. I think Wouter
van Heyst points out other valid use cases. I've also worked on software in
the past in which the proper Makefile to use was pointed to by using a
symlink.

> But if you want to support distribute software development
> with trees and repositories hosted on an uncontrolled set
> of file systems (including networked systems) then I claim
> a "good" tool should foster practices that will trigger as
> few unpleasant surprises as possible.  This implies a limited
> abstraction of a directory tree of files such that one can
> reasonably expect to be able to instantiate that tree
> successfully on nearly any plausible platform.

I would be happy discuss the benefits and drawbacks of various development
approaches. I don't, however, think that a discussion of enforcing
policies belongs in the tool. I've been down that road with Arch and I see
where it leads.

I think is perfectly appropriate for a project to say "No, we won't take
advantage of this particular feature because it hampers some of our
users". I don't think its appropriate for any particular tool to make that
choice on its own.

> This discussion so far has been about symlinks.  I think
> that your general philosophy is embodied in this statement:
> 
>   This would leave the responsibility of deciding
>   whether or not to use symlinks in the hand of
>   individual developers, where it belongs.

Yes. I would go even further and openly admit to having a knee-jerk
reaction to any arbitrary limit. A chain is only as strong as its weakest
link. There isn't a need to make a policy decision in the tool.

> So the get succeeds and does not tell the "getter" that
> he is hosed.  Remember that the symlinks are in a source
> tree, not the result of a build step.  Presumably that
> build depends on the semantics of the symlink.  It is
> possible that had the get had simply cloned the symlink's
> target building might have succeeded.  But with Aaron's
> proposal it is nearly guaranteed that the build will fail.
> So you call it success even though he leaves behind a broken
> tree that cannot be built.  I call it dysfunction.

I see you point. I would complain to the that which broke -- namely either 
the operating system or the development team that made the decision.

But when should we stop? Should we ban filenames that are illegal on some
filesystem or another? Refuse files based upon capilization (example:
"README" and "readme" are two different files on *nix).  Should we take
the next step and prevent filenames that are longer than eleven characters
long? 

Perhaps, while we're at it, we should dictate that files that start with
"," can be arbitrarily deleted by the RCS and that files that "+" won't
automatically be copied if one runs "bzr branch". 

> I want to catch errors early.  Aaron's proposal pushes
> detection ever later.  Instead of discovering a cross-
> platform problem at the point of doing the get he would
> wait until attempting the build.  I want to catch the
> error at the time the developer attempts to place an
> object under version control.

I believe you've made a mistake. A non-portable decision is not
necessarily a error. Its just non-portable. 
  
I think there's definitely room for you to write some sort of
"portability" plugin that overrides add and refuses to allow for
adding/comitting any files that are not portable.  This gives people that
are concerned about portability the ability to keep close watch for what
happens.

> predicting what my code should / will do I simply declare
> that situation / use case to be illegal.  This leads to a
> design in which ALL unobvious /  controversial semantics /
> behaviors must be requested explicitly.  (I will readily
> admit that this style is at variance with the *nix attitude
> of the "the semantics are whatever the first release did".
> But it has stood me in very good stead with my documentation
> and customer support organizations.)

Symlinks aren't controversial on most operating systems. Its a carryover.


> 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.

You would astonish me if you gave me a RCS that by default couldn't handle
symlinks.


-- 
James Blackwell's home :  http://jblack.linuxguru.net
Gnupg 06357400   F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060113/e0e18edb/attachment.pgp