Karl Fogel wrote:
> Nuutti Kotivuori <naked@iki.fi> writes:
>> *** Generated text method
[...]
> 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? :-)
Still to be decided :-)
> 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.
Well - the properties and contents for all of them would be nice to
specify beforehand. Then when adding support to create and
'disassemble' them, we can see again that is it easier to do them all
at once or not. And then again when making the client actually support
them.
My hunch here is that since there will be absolutely no difference in
behaviour between these - doing them all at once lessens the chance of
having to recode anything and provides cleaner changes in general. But
we'll see when coding the actual thing.
On an abstract level - I agree. Symlinks is what needs to get working
first, then the others.
>> 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.
Well yes and no. Depends on what we want - with regard to conflict
handling as well. For example, think about an interface where
'svn:special-file' is just a boolean variable - yes or no. And the
text-contents of the file would be:
,----
| File-type: symlink
| Destination: /dev/null
+----
| File-type: fifo
+----
| File-type: device
| Type: block
| Major: 10
| Minor: 20
`----
Then changing between file types would be trivial - and conflicts
could handled very easily.
But again - this is something I thought just now - 5 minutes ago :-)
> What about portability? How do Mac and Windows handle this?
Well, as a simple solution I though to just have the files appear as
normal files - contents being what they are in the repository. For
this purpose also, it would be nice to easily see from the contents of
a file that it is indeed a special file.
Another choice could be to just put "placeholder" files in the working
copy which verbosely explain what is going on. And yet another choice
would be to just not have any files at all.
Input is appreciated on these. I will probably cook up some kind of a
proper suggestion for the types - and then we can iterate from that.
But I don't see this as a terribly pressing issue - so I'm not going
to rush with this. This was just the first raw idea :-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 13 00:02:15 2002