On Friday, October 11, 2002, at 10:37 AM, Zack Weinberg wrote:
> On Fri, Oct 11, 2002 at 07:42:49PM +0300, Nuutti Kotivuori wrote:
>> ** Special files in a live working copy - yes
>>
>> Often one encounters the need to have special files inside the working
>> copy itself. These can be generated by a script inside the working
>> copy ofcourse - but it generates a problem in the general handling of
>> the files, when they do not carry over properly between updates and
>> other operations. It would be a lot easier to have the client actually
>> handle the files properly.
>>
>> This is what I wish to solve. To make the subversion client able to
>> handle a working copy with special files in it.
>
> Let me throw out some concrete suggestions for this.
>
> In general, special files are not going to be edited directly. You
> listed client-side symbolic links, named pipes, and device files as
> examples of special files -- none of these are editable as such. What
> one normally does is destroy and recreate them using different
> parameters, using tools for the purpose. For these files, we can
> represent them in Subversion with two properties:
>
> svn:construct -- If this property is set on a file, that file is
> considered special. The text of the property is
> a command which should be executed upon
> checkout, which is expected to create the file.
> See below for details.
>
> svn:deconstruct -- If this property is set on a special file, it
> gives a command to be run to determine the new
> text-base of the file. Since special files may
> not have meaningful modification times or
> checksums, it is necessary to run this command
> any time the client wants to know if the special
> file has been modified.
>
> The commands run by :construct and :deconstruct are executed in the
> immediate parent directory of the special file. There is a limited
> set of %-escapes which can be used to parametrize them:
>
> %n name of special file, without any directory components
> %t pathname to special file's text-base
> %T contents of special file's text-base
>
> [others might be added as they prove useful]
>
> So, for example, a symbolic link could be represented by
>
> svn:construct = "ln -s %T %n"
> svn:deconstruct = "readlink %n"
>
> If :deconstruct is not set on a special file, that file is considered
> unmodifiable (except by changing its properties). This is appropriate
> for a FIFO:
>
> svn:construct = "mkfifo %n"
> svn:deconstruct (not set)
>
I have two conflicting opinions about this approach. I like the
flexibility because it would make the support of bundle files (as has
been discussed a while back and eventually dismissed) possible. For
instance, an svn:de/construct command to un/tar a *.app directory would
enable keeping Mac OS X bundles in revision control without making them
unusable by putting .svn directories throughout them. And other neat
uses exist too...
My other opinion is that for special files that are as (unix) standard
as symlinks (and maybe FIFO's), the support should exist within
subversion instead of depending on external commands to exit and work
the same across all platforms. For instance, Mac OS X doesn't have a
readlink command by default. (I got it from fink.) Also someone else
could put svn:construct = "rm -rf / %n" and boy would I be in trouble.
And thirdly, are device files (or even the commands to create them)
portable across unix platforms? I don't think that's a reason not to
support them (I'm actually getting excited by the idea of keeping whole
linux installs in svn for our production machines), but it's another
thing to think about.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 21:13:17 2002