Nuutti Kotivuori <naked@iki.fi> writes:
> *** Generated text method
>
> This is the next phase, requiring a bit more effort. For this method,
> properties would no longer be kept for the special file, only a single
> property detailing the type of the special file. Instead the contents
> of the file define the attributes.
I like this much better. One property, `svn:special-file', can have
the value `symlink', `device', or `namedpipe', and then the contents
of the (text-base) file define the rest.
> When the working copy is checked out, the file is created according to
> the contents of the file in the repository. But this would be a
> two-way conversion - from a simple text-format to a special file and
> from the special file to a text-format. This means that when the
> special file is modified - it would show up as locally modified. And
> 'svn diff' could show the difference between the text-representations
> of the files. Ofcourse, like everywhere, the text-base would contain
> just the text-representation.
Yes. I hadn't even read this paragraph when I wrote the above. We
are on the same wavelength here.
> How conflicts should be handled is ofcourse yet another issue. Should
> there be three text-representation files in the working copy which
> could be handled properly - and then 'svn resolve' would substitute
> the text-representation with the actual special file? Perhaps.
Not sure here, yeah. Also have to deal with a type change -- what if
one side of the conflict is a symlink, and the other side is a device,
or just a plain file? :-)
> This would be more work than the simple solution above, but is much
> better ofcourse. The problem here is that one has to be careful not to
> trigger too many cases where the files would need to be handled
> specially - the 'svn:external' stuff showed pretty well how these
> things can escalate.
Agree, though actually I think svn:externals didn't escalate much at
all. Other things did, though, like svn:keywords.
> * What's next
>
> I would want any input you can muster out of yourselves on this
> matter. I am still very unsure how to best achieve this all. I am
> willing to do a lot of the coding, unless I get terribly bogged down
> at work again - but I hope to achieve all this with the absolute
> minimum of code and special cases.
The only suggestion I have is to first pick one type of file (say,
symlinks) and implement that. When it's working, then we add device
files. When that's working, we move on to named pipes.
One thing at a time.
> If work should be started based on this, next would be defining the
> actual formats for the special files and specifying what to support
> and what not to. Then things can be added by small patches with tests.
For symlinks, the content of the text-base can just be the text of the
symlink. Seems pretty straightforward.
What about portability? How do Mac and Windows handle this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 19:09:58 2002