Re: Suggestion for special file storage in 1.0

[Karl Fogel <kf...@newton.ch.collab.net>]

Nuutti Kotivuori <na...@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

Re: Suggestion for special file storage in 1.0

[Nuutti Kotivuori <na...@iki.fi>]

Karl Fogel wrote:
> Nuutti Kotivuori <na...@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