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)
Another broad category of special files are derived text files. These
are generated by some procedure from other data in the repository.
Again, they are not normally edited directly. Examples are the
'ChangeLog' file in GNUish projects, which wants to be auto-generated
from the repository's commit logs, or a 'configure' script that gets
generated from 'configure.in' stored in the repo.
This case can be handled with a third property, but it's going to
require more work to implement.
svn:dependencies -- If this property is set on a special file, it
gives a list of other files in the working copy,
as pathnames relative to the immediate parent
directory of the special file.
The special file is to be constructed when and
only when a checkout changes at least one of
these files. A special file can depend on other
special files, perhaps with their own
dependencies; then they are constructed in
topological order.
The magic dependency "/always" indicates that
a special file is to be reconstructed on every
checkout (note the leading slash - normally
absolute pathnames are invalid in :dependencies).
So, for instance
"configure"
svn:construct = "autoconf"
svn:dependencies = "configure.in","aclocal.m4"
"ChangeLog"
svn:construct = "../path/to/log2cl"
svn:dependencies = "/always"
The major reason this is more work is the need for transitive
dependencies, which effectively requires a mini-Make in libsvn_wc.
This may be too much complexity; perhaps we should stick to
hand-rolled "autogen.sh" scripts for that sort of thing.
zw
---------------------------------------------------------------------
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:38:14 2002