FOSSIL UV enhancement requests
(1) By anonymous on 2020-07-23 12:31:15 [link] [source]
FOSSIL UV LIST followed by an optional string to match only those entries containing that string, as if with SQL LIKE '%string%'.
It will help locate the needed entries much faster in a very long list.
Yes, I know it can be done with an external grep-like utility but it'd be much nicer to have it built-in.
(It seems a rather trivial code change, right?)
If FOSSIL UV EXPORT is missing the OUTPUT parameter use the FILE parameter instead of stdout, so that one does not have to repeat for same file names, which is the most common use case. Example:
Instead of
FOSSIL UV EXPORT readme.txt readme.txt
do
FOSSIL UV EXPORT readme.txt
As an extension to the above,
FOSSIL UV EXPORT abc
where abc is a directory name (indicated by a following /)
to extract all abc/* to the corresponding subdirectory in one command.
Thank you.
(2) By Richard Hipp (drh) on 2020-07-23 12:40:51 in reply to 1 [link] [source]
This capability already exists with the --glob and --like options to the "fossil uv list" command.
(3) By anonymous on 2020-07-23 12:56:36 in reply to 2 [link] [source]
I didn't know there were options added to the ls command.
Certainly a later addition as my 2.8 fossil help uv command does not show any options for ls sub-command.
(Yup, I just downloaded 2.12 and it's there. Thank you.)
That tool care of my first request. Any hope for the other two?
(4) By Stephan Beal (stephan) on 2020-07-23 13:07:58 in reply to 3 [link] [source]
Any hope for the other two?
FWIW, the second one seems likely to upset Unix users (myself included), not to mention potentially breaking existing scripts (something we dislike doing). Maybe a flag which tells is to output to the same name would suffice.
The 3rd one seems extremely special-case and unintuitive to me (but that's just my opinion). Perhaps another flag would make its intent clearer.
(5) By anonymous on 2020-07-23 13:12:52 in reply to 4 [link] [source]
The 3rd one seems extremely special-case and unintuitive to me (but that's just my opinion). Perhaps another flag would make its intent clearer.
There is currently fossil add dir/* which adds all dir subdirectory files in one command. So, it seems like a logical complement.
(6) By Stephan Beal (stephan) on 2020-07-23 13:20:31 in reply to 5 [link] [source]
There is currently fossil add dir/* which adds all dir subdirectory files in one command. So, it seems like a logical complement.
That's a valid argument, but "uv export" and "add" are, IMO, completely different beasts.
That said: i don't use unversioned files in fossil repos, so have no real objection either way (except for the 2nd one, which currently works "the Unix way" and should, IMO, continue to do so).
For the second one my proposal would be something like:
fossil uv export blah --same-name
(Hopefully a better flag name can be found, though.)
Ideally it could instead be:
fossil uv export blah --to blah
# Functionally equivalent to:
fossil uv export blah > blah
Which would allow your proposed feature without any compatibility breakage, but breaking backwards usage compatibility is something we strongly like to avoid.
(7) By anonymous on 2020-07-23 13:36:40 in reply to 6 [link] [source]
That was supposed to be uv add not add. My second message with this correction didn't make it.
(8) By anonymous on 2020-07-23 13:48:24 in reply to 6 [link] [source]
Ideally it could instead be:
fossil uv export blah --to blah
Functionally equivalent to:
fossil uv export blah > blah
I don't get it.
That's typing even more than the way it is now, and with the (current) risk of accidentally renaming the file due to typos.
Maybe fossil export file.txt -s
(-s for same name)
(9) By Stephan Beal (stephan) on 2020-07-23 13:56:01 in reply to 8 [link] [source]
I don't get it.
If the interface worked like that, your proposed addition would be completely backwards-compatible (compatibility being my only objection to it).
Perhaps if the output name is a directory, it should output the file with the same name in that dir, allowing your feature to be implemented as:
fossil uv export blah .
(10) By Stephan Beal (stephan) on 2020-07-23 13:59:25 in reply to 7 [link] [source]
My second message with this correction didn't make it.
When an anonymous poster edits a pending post, it creates a second copy. When that happens, and no edit is glaringly obvious, the moderator (in this case me) might just randomly pick one of the two to approve and reject the other to avoid what appears to be a duplicate post.
(11) By george on 2020-07-23 15:58:41 in reply to 1 [link] [source]
This is not directly related to the initial requests (except maybe the third), but since this topic (unversioned files) is concerned...
Please consider the opportunity to have unversioned files arranged as a directory tree, not just as plain list of files. I believe this might be very convenient in some use-cases. If it were possible then one could add/export a particular directory on the filesystem directly, without the need to rearrange and/or rename files.
Perhaps, initially this could be achieved by allowing "/" in the file names with the appropriate handling of such cases. Later, if this feature gains popularity, then Fossil's standard tree-explorer could be adopted to support both versioned and unversioned files.
Does it make sense?
(12) By Stephan Beal (stephan) on 2020-07-23 16:13:05 in reply to 11 [source]
Does it make sense?
It conceptually makes sense, but it stretches the intended scope and complexity (==code to maintain) of uv well beyond its current limits. uv is not intended to provide a general-purpose file management/backup/distribution mechanism. It's there primarily to support publishing of distributables for a project without requiring (A) out-of-repository filesystem space or (B) checking those files in to the repo.
That said: as Warren so elegantly put is, the fossil project is essentially a "do-ocracy," in which the features which get added to it are those which someone "does" (==writes the code for). In other words: such features will almost certainly be added as soon as they itch someone enough to prompt them to implement them.
(13) By anonymous on 2020-07-23 16:30:11 in reply to 11 [link] [source]
one could add/export a particular directory on the filesystem directly,
Right now (even since FOSSIL v1.xx) you can do this:
fossil uv add dir/*
and have all files inside dir subdirectory added to the UV list as
dir/file1
dir/file2
dir/file3
One command! Which is great. And they are stored as such (i.e. with the directory as part of their name).
So, this capability is already there. The problem is the opposite is not currently possible unless you do one file at a time. So, ideally:
fossil uv export dir/*
and have
dir/file1
dir/file2
dir/file3
created in a single command.
BTW, there is a bug with fossil uv add dir instead of ... dir/*
A zero-size file, named dir, is added. One would expect it to see dir is actually a directory, and do the equivalent of dir/*
(14) By graham on 2020-07-23 19:47:52 in reply to 13 [link] [source]
fossil uv add dir/*
I don't think this functionality is provided by Fossil: it's just the Unix shell expanding dir/* to the list of matching files. As far as Fossil is concerned, you could have typed them manually. (On Windows, where it's up to programs to expand wild-cards, the above doesn't work).
(This isn't a reason not to make fossil uv export dir work as you want, just pointing out that it's not the case that Fossil "supports" one and not the other).
The fossil uv add dir issue is probably the same sort of thing as this thread on the SQLite forum. It appears to be reading the "file" specified without noticing that it is a directory.
(15) By anonymous on 2020-07-24 12:57:23 in reply to 14 [link] [source]
Actually I'm on Windows, and fossil uv add dir/* works.
(16) By graham on 2020-07-24 14:19:58 in reply to 15 [link] [source]
Odd... I've just tried it again and – as you say – it worked: sorry for my mistake. (I definitely got an error message when I first tried it... either I mis-typed something, or "something weird" happened!)
(17) By george on 2020-10-30 00:33:41 in reply to 12 [link] [source]
Can I please have a "commit bit"? It's hard to practice a "do-ocracy" otherwise ;-)