Hi,
On 26/06/18 13:22, j. van den hoff wrote:
> 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.
>
I'm using Fossil in this precise context for storing inside a repository
a large PDF file that is produced from LaTeX source files. What is most
surprising to me, is the fact that I need to add again the unversioned
file *every time* before I want to do `fossil uv -v` to update such file
in the repository.
So, I'm pretty interested in this thread and the solutions and
suggestions that you arrive. Using Fossil as a DVCS for reproducible
documentation, research and publishing is the exact case you're
advocating for and the features for least surprise regarding unversioned
files inside the repository are pretty pertinent there.
Cheers,
Offray
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
