On Nov 20, 2017, at 1:33 PM, Warren Young <war...@etr-usa.com> wrote:
>
> I see a new wiki article:
>
> https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG
Shallow clones bear some thinking, too.
Let us posit that “fossil clone” takes a -shallow option with no argument,
telling it to fetch only the artifacts for the files at the tip-of-trunk. A
-shallow clone should also pull non-closed tickets and wiki articles where the
latest checkin is not empty.
To allow shallow clones of a different branch than trunk, “fossil clone” could
take a -branch option. If you then say “fossil up trunk” from the checkout of
such a clone, it would fetch all artifacts checked in on the trunk since clone
time.
More broadly, “fossil update” of a shallow clone never pulls history past the
clone date unless you specify an older date or checkin ID with the VERSION
argument.
Then let us add -limit which takes the same VERSION argument as fossil update,
which limits the depth of the history:
$ fossil clone -limit 2017-11-01 https://fossil-scm.org
$ fossil clone -limit abcde12345 https://fossil-scm.org
$ fossil clone -limit release https://fossil-scm.org
(Here you see me using the new clone-and-open behavior we will shortly be
getting. Ehehm. ;) )
The last is interesting: it means “give me the latest tagged release plus all
changes made since then.”
I’d like to see a small expansion of VERSION:
$ fossil clone -limit "30 days" https://fossil-scm.org
It needs a new syntax because you can’t just take a bare integer as a day
count, since that could be ambiguous with checkin IDs. Simple suffixes like
“30d” are also ambiguous, so if we require the space, then it breaks the
ambiguity. It lets us add other multipliers, too, like “1 year”. All of this
should be easy to do with SQLite date arithmetic.
I say it should modify the meaning of VERSION because it has applicability
outside of shallow clones. “fossil update ’30 days’” means “check out the
version closest to 30 days ago.” It could even take an ignored “ ago” suffix
purely for readability, such as in scripts. This might make starting a bisect
a bit easier.
If multiple -limit arguments are given, Fossil will take the oldest one as the
true limit, so you can use it to list all the tags and branches that must be
present in the clone; if the oldest listed item is a branch, you get the tip of
that branch and everything newer than it. This would be useful in automated
system deployment scenarios, where a script must specify the requirements for
the checkout without knowing in advance which of the -limit values are oldest
at any given point in time. (Puppet, Chef, Ansible…)
My current sense is that -shallow and -narrow should interact with AND logic.
This:
$ fossil clone -limit release -narrow src https://fossil-scm.org
should result in only a src subdirectory which won’t build because it’s missing
Makefile.in, configure, auto.def, and autosetup/ at least. If the user wanted
a buildable “release” clone, he should have left off the -narrow option; else,
why allow these options to interact at all?
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
