[rfc] Proposal: fake symlinks support on windows

[Alexander Belchenko]

Martin Pool пишет:
> On 18 May 2006, Alexander Belchenko <bialix at ukr.net> wrote:
> 
[skip my use case]

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

I think so.

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

Perhaps it too complicate. I love this one: explicit is better than
implicit.

> 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

Yes, this is exactly how I imagine fake symlink support.

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

Only in some circumstances. And this cases might be clearly documenting,
and therefore we convert "bug" into "feature". :-)

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

Yes, but it require to mix windows and cygwin. I think it's not ususal
use case where developer need to switch between windows and cygwin very
frequently. I think it will be a project policy when and how use
different environment: when for editing source files and work with
source control tool, and when to build and test software on different
platform.

More proposal
-------------
I think if bzr can have inside .bzr control directory additional
information about subtype of working tree it will give ability to
prevent bzr do illegal thing when user mix environment or try to make
bzr operations with working tree from non-native platform. I have the
idea to put into .bzr/checkout some additional files that will show to
bzr itself on what filesystem checkout was be made and how to interpret
such things as symlinks and executable bit. Probably I need to write
another proposal for that things.

In short: if bzr check out tree with symlinks it can put into control
directory special file, that should be valid symlink for current
platform/filesystem. Because name of this file will be constant so bzr
can easily detect to what filesystem this checked out working tree
belongs. And if current platform name does not match to type of checkout
then bzr should at least emit warnings to user about possible problems
with operations that affects working tree. But better if bzr will blocks
commands that operate with working tree (add, commit, status,
rename/move/mv, etc.) with explanation like following (as example of
concept):

"""Bzr cannot guarantee proper operations with working tree
that checked out on platform XXX while it running on platform YYY.
Please check out working tree of this branch on your platform
or convert this working tree to native format of platform YYY."""

This approach will be backward compatible, because when in .bzr/checkout
there is no special symlink file then bzr operate in usual way.
Otherwise bzr will compare working tree platform with running platform
and decide in what mode it should work (enable operations or block
them). Also this information can be visible in output of 'bzr info'
command, per example:

Format:
        control: Meta directory format 1
   working tree: Working tree format 3 (Cygwin)      <<<<<<<<<<
         branch: Branch format 5
     repository: Knit repository format 1

And it possible to make conversion tool for reading symlinks produced on
another platform and converting them into symlinks supported (or
simulated) on current platform, because bzr has additional meta-info in
inventory about what files are really symlinks. So bzr don't need to
make false assumptions, and bzr will not slowdown their operations with
working tree to autodetect symlinks that come in from another platform.
And symlinks never be mixed between platform (from bzr's point of view).

What you think about this concept?

--
Alexander