On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth <andrew.m.g...@gmail.com>
wrote:
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 specific projects.
On 06/26/18 10:31, Richard Hipp wrote:
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 feature
creep as people want to do any of the following and more:
- 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 right away.
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).
so my question would be:
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 into fossil.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
