I see a new wiki article:
https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG
I’m glad to see shallow and narrow clones being planned.
The section on narrow clones should specify whether these can take on a life
independent of the parent repository. That is, can they be used to shard a
repository, such as one where each top level directory (TLD) is a separate
project with no cross-TLD checkins? What happens if the narrow clone is
re-shared?
$ fossil clone --narrow src https://example.com/x x-src.fossil
$ mkdir x
$ cd x
$ fossil open ../x-src.fossil
$ fossil server
If I then clone this narrow repository, does the clone’s /file URL show files
present at the root of the grandparent repository and not available in the
parent?
I’d also like to be able to choose to make this permanent, popping a layer of
the directory hierarchy, so that the narrow clone’s /file URL shows the
contents of /src by default, not a lone “src” subdirectory.
If there are cross-TLD checkins in this scenario, does the clone fail, warn, or
proceed silently? It may be an important matter of policy since if checkin
[1234abcd] is a cross-TLD checkin, “fossil up 1234abcd” means something
different in a narrow clone than in a complete clone.
I bring all of this up because I’d like both major behaviors for different use
cases:
1. Sharded repositories where the permanently-narrow clones are re-shared under
new names with no intention of going back and widening any of them, so the
clone operation should warn if the clone has checkins that are incomplete
because of the narrowing. This would be used to break up multi-project
repositories into individual repositories.
2. Temporary narrow clones which simply save bandwidth and disk space, which
automatically widen later on demand. If you roll back to a checkin that refers
to artifacts not present in the local clone but they are present in the remote,
the artifacts should be fetched at that point.
It wouldn’t break my heart if we only get behavior #2 at first, since the
resulting repository should still be faster as well as smaller, simply due to
the limits of logarithmic scaling. But I would like frosting on my cupcake,
too, if I can get it. :)
Topic shift:
There is one more thing Git really gets right compared to Fossil: single-step
clone-and-open. We should be able to do the same:
$ fossil clone https://fossil-scm.org
When the FILENAME parameter is not given, it produces a “Fossil” subdirectory
containing the contents of tip-of-trunk, with the directory name coming from
the project configuration under Admin. The SQLite repo file is stored inside
the subdirectory in a hidden file; I propose .fslrepo.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
