[rfc] Proposal: fake symlinks support on windows

[Martin Pool]

This proposal looks good to me.  I like the idea of leaving the symlink
method unspecified until we actually need to create one so that you can
move them around more easily.

We should make sure to keep the working inventory updated with
information on symlinks so that we can remove or recreate them as
needed.

Could you please copy and paste this onto a spec in the wiki so there's
a record of it?



> 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
> 
-- 
Martin Pool