On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth
Post by Andy Goth
I think the next project that needs this feature should write a
utility script for themselves that uses the uv commands to extract
files however makes sense for them. This live experimentation is
necessary to figure what is needed in practice. No one is forced to
wait for any changes to be made to Fossil itself. One day, a set of
best practices (i.e., a vague consensus on which compromises and
heuristics most people can live with most of the time) will emerge,
at which point Fossil can adopt them as useful defaults, but people
should always be able to write new scripts that work best for their
Post by Richard Hipp
My thought was to provide a new setting (perhaps versionable) that
specified a directory relative to the root of the check-out into which
unversioned files are written whenever one does "fossil update" or
"fossil checkout". If the setting is missing or empty, then Fossil
works as it does now. If you turn on the setting, though, then the
unversioned files work just like other files in the check-out, except
that Fossil never records their history.
I overall like the idea, but I can envision an endless stream of
- Deal with files having platform-incompatible names (slashes,
backslashes, drive letters, characters unsupported by the filesystem)
- Extract only files within certain size ranges
- Extract only files within certain date ranges
- Extract only files matching certain glob patterns
- Update the unversioned files when checking in
- Get diffs showing which unversioned files have changed
- Handle new files being added to the unversioned directory
- Reverse filename mapping done for platform compatibility when
checking in or adding new unversioned files
- Selectively check in unversioned files along with the rest of the check-in
And on it goes. All of the above can be done today via shell
scripts, so projects wanting to experiment are invited to get started
I dislike feature creep and endless "please implement this for me"
requests, too. but I don't think this argument applies here, really.
anyway the developer(s) decide what they implement and what not...
from this thread I have learned in the meantime, that uv-files where
intended for something different than what I would have guessed
("created for the purpose of providing a place to store build products
when Fossil is used as a server") and that uv-files usually(is that
right?) are residing outside of the checkout. so be it. and then I can
understand why fossil does what it does with uv-files (and what it
does not, namely providing a `fsl uv up' command that would do the
same with uv-files that `fsl up' does with versioned files.
all the possible issues with file system /OS issues etc. are sure
valid but to the extent that fossil handles these with versioned files
it could do the same with uv-files (at least as long as their
pathnames are relative to the checkout root).
is their any strong argument against a `fossil up -u' command? would
it be undesirable to have? (if it really is going to be implemented
und whether drh is willing to invest the time is a different question,
naturally.) I think it would be quite valuable for assorted projects,
notably those depending on large binary files such as jpeg-images (or
libs) that are *project-specific* and prone to multiple changes over
the duration of the project but where tracking changes of these files
is not required. I simply would find it useful to be able to do `fsl
up; fsl up -u' (or both with a single command) in order to bring my
checkout including uv-files up to date...
and yes, I will write a shell or TCL script to do this, if everything
else fails. but it will be inferior to integration of this feature
a large PDF file that is produced from LaTeX source files. What is most
in the repository.
suggestions that you arrive. Using Fossil as a DVCS for reproducible
files inside the repository are pretty pertinent there.