[rfc] Windows symlink support

James Blackwell jblack at merconline.com
Fri Jan 13 22:49:25 GMT 2006


John,

I'm not sure that I understand your point correctly. Thusly I've recapped
my understanding of what you're saying so that you can clear up any
misconceptions that I have. 

My undestanding is that you're saying 'do not support symlinks'. Your
reason for not supporting symlinks is based upon a concept that bzr should
be reduced to the largest common denominator. Since fat filesystems do not
directly support symlinks, bzr should not as well. As anecdotal evidence
you reference git, which also does not allow symlinks.

Did I get that right? If so, then I'd like to respectfully disagree. I'll
take your word for it that git manages to get by without symlink support.
I can't imagine though that any contemporary, generalized revision control
system could get away with it. I know that many people depend upon using
symlinks within their branches. I use them myself. :)

Aaron's proposal covers how to track symlinks in a branch so that one can
still do a get on win32 and not have the system break down completely.
I'm not sure that there are many good use cases for it, but I wouldn't be
surprised.

This would leave the responsibility of deciding whether or not to use
symlinks in the hand of individual developers, where it belongs.



On Fri, Jan 13, 2006 at 05:01:53PM -0500, John Yates wrote:
> I would hate to see this suggestion come to fruition.
> (Similarly I would hate to see bzr expose hard link
> semantics within its tree abstraction.)
> 
> The git project has formulated a clean abstraction
> of a tree-structured namespace:
> 
>   http://www.kernel.org/pub/software/scm/git/docs/#Discussion
> 
> They have done this in spite of making not the
> slightest peep about git being supported in any
> environment other than Linux.
> 
> Bzr by contrast professes to want to be a viable
> tool in non-*nix environments -- notably Windows --
> but tends to develop utterly ad-hoc semantics
> based on use-case wishes.
> 
> >From the very top of Aaron's wiki page:
> 
>   Add support for symlinks to bzr-on-windows, so that
>   windows users can collaborate on projects which use
>   symlinks in their source trees. 
> 
> This seems an ill-thought out use case.  If symlinks
> are used in any general way in the source tree such
> that any tooling used to build the project needs to
> follow those symlinks then in reality that project
> has written off developers on Window boxes being
> real participants.  Further down the page Aaron
> suggests this use case:
> 
>   Project FunFoo is started on Linux. For convenience
>   in building their code, they add some versioned
>   symlinks to their bzr directories. Developer jrandom
>   tries to use FunFoo, but discovers some win32-specific
>   bugs. He gets a branch of FunFoo using bzr, fixes the
>   bugs, commits. The *nix developers merge jrandom's
>   fixes without issue. To them, it is not apparent that
>   the changes were committed on Win32. 
> 
> This seems fanciful.  Is a Windows developer to operate
> in such a manner that he nor any tools/scripts/etc that
> he might run would need to follow the symlinks?  As I
> read the use case the project sounds to be one in the
> arch/tla mold... vaguely interested in windows but making
> no real commitment thereto.  jrandom seems to be not an
> actual project participant but simply a enthusiast who
> spots an issue by simple inspection.
> 
> 
> Contrary to Aaron's proposal, were I setting up a project
> in which I wanted to ensure that Windows developers were
> able to contribute I would want to do all that I could to
> ensure that my project tree never got polluted by symlinks.
> 
> My preference would be for bzr to simply say "No" to
> both symlinks and hard links.  Barring that, if bzr
> really must version links when hosted on a file system
> supporting them then I REALLY want a way to tell bzr that
> my project has forbidden links of any ilk.
> 
> A developer may create links locally in his tree for any
> local hacking he may want to conduct but they cannot be
> made into versioned objects.
> 
> /john
> 
> PS: Is it not the case that if bzr admits link semantics
>     into its tree abstraction then it is more or less
>     closing the door on leveraging git technology and/or
>     any future git convergence?

-- 
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/e8fd2d74/attachment.pgp 


More information about the bazaar mailing list