[rfc] Proposal: fake symlinks support on windows

[Martin Pool]

On 18 May 2006, Alexander Belchenko <bialix at ukr.net> wrote:

> I have embedded system with OS Linux with Python 2.3 installed. I can't 
> at this moment upgrade to python 2.4. All business logic stored in some 
> sort of virtual disk that mounted to /home and provide main programs for 
> my embedded system. This virtual disk is 2MB in size, and new versions 
> distributed to customers via internet. I want to use bzr as version 
> control and archiving tool. But I need to have support of symlinks to be 
> able checkout versioned files to compare and/or change some of 
> programs/scripts. Usually I will not change symlinks -- only change 
> regular files. At this moment it's all. I need to import existing 
> archives via SFTP to bzr repository that hosted on windows/cygwin 
> machine and need to create utility to mirror state of arbitrary revision 
> of tree onto native linux machine.
> 
> I'm become aware that there is more use cases. But creating too wide 
> support of fake symlinks may be not worth big efforts. Because today bzr 
> has another more actual problems.

So the basic use case is that if you have a working tree on windows, you
should be able to read and manipulate symlinks.

This does not, in itself, necessarily require having anything present on
disk in the working directory - we could just keep them in the working
inventory and give you commands to read them from there.  We'd need
special object so that on platforms using this approach, the absence of
a symlink on disk doesn't mean it's treated as missing.  Perhaps this
will complicate things.

So the possible justifications for having something on disk are

 - it makes the handling of them more consistent between unix and
   windows
 - it interoperates with other programs particularly under cygwin 
 - it shows the user something if they look at the directory

contra this we will have two different types of symlink in the working tree.

.lnk files seem pretty kludgy (e.g. you can have foo and foo.lnk coexisting,
etc.)

-- 
Martin