Re: [fossil-users] Fossil-NG ideas

[Ron W]

On Tue, Nov 21, 2017 at 6:43 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Tue, 21 Nov 2017 15:25:37 -0700
> From: Warren Young <war...@etr-usa.com>
> Subject: Re: [fossil-users] Fossil-NG ideas
>
> On Nov 21, 2017, at 2:09 PM, Ron W <ronw.m...@gmail.com> wrote:
> >
> > While I like the idea of a "smart default" for the file name, I'd rather
> have an "--open" (or "-o") option to trigger the automatic "fossil open”.
>
> So…you want to remain more difficult to use than Git in this regard?
>

"fossil clone -o URL" would still be 1 step instead of 4 steps.


> > 1. If the user actually wants to specify the name, the option would be
> needed, anyway.
>
> No, they’d pass the FILENAME argument to “fossil clone,” just as you do
> today.
>

My understanding of your proposal was that leaving off the file name would
be the trigger for the git-like behavior.

So, I would expect "fossil clone URL filename" to do what it does today:
Create a repository file with the specified filename. No more.


> This does open a new issue, however.  What does this mean:
>
> $ fossil clone https://fossil-scm.org/ fsl
>
> Do you:
>
> a) get a fsl subdirectory containing the contents of the Fossil trunk
> checkout, as Git would do; or
>
> b) get a fsl.fossil file, as someone up-thread apparently wants.  That is,
> assume the FILENAME argument is still a repository file name, and that if
> .fossil is not given as an extension, add it?  Or
>
> c) get a fsl file, as Fossil 2.4 and all prior versions do?


I would expect c - do as Fossil does, today.

If I want the git-like behavior, I'd type "fossil clone -o
https://fossil-scm.org/ fsl"

I'm all for "stealing" features from other VCSs. Just don't change break
existing command syntax.

As for something I'd suggest stealing, how about enhancing "fossil
checkout" to accept an optional URL?

When I first started using Fossil, one of the things that was confusing to
me is that "svn checkout" maps to "fossil open", not "fossil checkout". It
is still something I help others migrating from SVN to Fossil. If Fossil
did not have a checkout command, it would have been less confusing. What I
tell those I help is "Just use 'fossil open' and pretend there is no
'fossil checkout'."

Anyway, "fossil checkout" could be made more like "svn checkout" merely by
extending the syntax to allow an optional URL.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Joerg Sonnenberger]

On Wed, Nov 22, 2017 at 07:01:31PM -0500, Richard Hipp wrote:
> > (2) Store true differential manifests.
> 
> I'm thinking that Fossil-NG will probably do like Git and store
> separate artifacts holding the content of each directory.  (Git calls
> these "Tree Objects").  I need to do more research, but I'm thinking
> that for most check-ins, only one or two directory artifacts will
> actually change, even if there are dozens or hundreds (or multiple
> thousands as in NetBSD) of directory artifacts in a single check-out.

I'm not sure splitting it up on a per-directory level well help that
much. If you change a number of files in the same directory, they will
have the same prefix and compress well (even without doing any adhoc
prefix compression schemes). Changes are quite high that larger commits
will scatter around many directories, it's a common theme i.e. for API
changes in larger projects. The primary reason for storing tree objects
in something like git is the lack of better indexing structures, I would
say. In short, I would strongly distinguish between storage format and
working format, optimizing the former for compactness and building up
the latter when necessary.

> >
> > (3) Make cluster manifests non-permanent artifacts.
> >
> 
> I'm thinking of doing away with cluster artifacts entirely, and
> managing sync in some other way.

Having something like cluster artifacts can be useful, i.e. consider the
typical case of one central main server and many clients pulling from
it. If the server builds a ephemeral cluster ever so often and the
clients remember the last cluster they got, they can just ask the server
"what changed since this point". If the implementation of the
communication process is actually asynchronous, adding a few round trips
is not that bad as long as the waiting time is minimized. If the first
request from the client starts with the last "cluster", the server can
answer with the commits added on top. Client can filter out those it
already has and request the new ones. While it gets the new commits, it
can start requesting the file changes. Non-commit artifacts would
essentially work like new leaf commits. A new "cluster" can either
reference an existing one as delta or be send from scratch. It would
still allow the server to do regular garbage collection.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Richard Hipp]

On 11/22/17, Joerg Sonnenberger  wrote:
>
> (1) The need to parse all artifacts on clone. Artificates should be
> strongly typed, i.e. the system should at the very least distinguish
> fully between "content" blobs and "meta data" blobs. Only the latter
> have and should be parsed.

That is a good point.  I had already planned to do this, though for
reasons other than what you propose.  The fact that it reduces the
amount of parsing work on a rebuild is a bonus that I had not
previously thought of.


>
> (2) Store true differential manifests.

I'm thinking that Fossil-NG will probably do like Git and store
separate artifacts holding the content of each directory.  (Git calls
these "Tree Objects").  I need to do more research, but I'm thinking
that for most check-ins, only one or two directory artifacts will
actually change, even if there are dozens or hundreds (or multiple
thousands as in NetBSD) of directory artifacts in a single check-out.

>
> (3) Make cluster manifests non-permanent artifacts.
>

I'm thinking of doing away with cluster artifacts entirely, and
managing sync in some other way.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Joerg Sonnenberger]

On Mon, Nov 20, 2017 at 01:33:11PM -0700, Warren Young wrote:
> I see a new wiki article:
> 
> https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

There are two central design flaws in Fossil that affect larger
repositories and those are the repos that primarily benefit from
narrow/shallow clones. Properly addressing them is kind of a requirement
for either.

(1) The need to parse all artifacts on clone. Artificates should be
strongly typed, i.e. the system should at the very least distinguish
fully between "content" blobs and "meta data" blobs. Only the latter
have and should be parsed. This has a number of important implications,
but the easiest is that the number of artificates a rebuild or even just
a sync has to look at goes down by a factor of 2 at the very least. For
something like NetBSD src or pkgsrc, more like a factor of 10 (number of
blobs in total / number of commits, i.e. the average commit touches 10
files).

(2) Store true differential manifests. The current base line approach is
a somewhat crude approximation. It has the advantage that only two
manifests have to be parsed, but it makes the average manifest size much
larger for larger file trees. The same benefit could be obtained by
caching the file list, either every so often like the current base line
or on-demand. The difference is that the cached manifests are not
persistent meta data and don't have to be transfered.

I would also add a point (3) which is kind of related to (1):

(3) Make cluster manifests non-permanent artifacts. They can also
consume a good amount of space and their purpose could be served by a
Merkle tree as well. This is even more important when doing single
branch sync.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 21, 2017, at 2:09 PM, Ron W  wrote:
> 
> While I like the idea of a "smart default" for the file name, I'd rather have 
> an "--open" (or "-o") option to trigger the automatic "fossil open”.

So…you want to remain more difficult to use than Git in this regard?

That’s not very Fossil.

(Yes, I just adjectived your noun.  Deal with it.)

> 1. If the user actually wants to specify the name, the option would be 
> needed, anyway.

No, they’d pass the FILENAME argument to “fossil clone,” just as you do today.

This does open a new issue, however.  What does this mean:

$ fossil clone https://fossil-scm.org/ fsl

Do you:

a) get a fsl subdirectory containing the contents of the Fossil trunk checkout, 
as Git would do; or

b) get a fsl.fossil file, as someone up-thread apparently wants.  That is, 
assume the FILENAME argument is still a repository file name, and that if 
.fossil is not given as an extension, add it?  Or

c) get a fsl file, as Fossil 2.4 and all prior versions do?

> 2. By not requiring the option, it would be hiding one of Fossil's advantages 
> over git and Hg: Multiple working copies without the overhead of multiple 
> repository copies.

Easily handled via either:

$ mkdir ../x ; cd ../x ; fossil open ../y/.fslrepo branch-x
$ mkdir ../x ; cd ../x ; fossil open ../y branch-x

In the second case, it sees that you’ve given it a directory name and that it 
contains a .fslrepo repository file.

> 3. Adopting features from git is good, but let's not make Fossil too much 
> like git.

Where it costs us nothing but development time and makes Fossil easier to use, 
let’s steal as much as possible. :)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Ron W]

On Tue, Nov 21, 2017 at 4:09 PM, 
wrote:
>
> Date: Tue, 21 Nov 2017 16:08:20 -0500
> From: Richard Hipp 
>
> The overhead for a small batch of commits non-zero but it is
> manageable.  A full clone, on the other hand, is too expensive.  To
> give Fossil the ability to service clone requests from git or hg
> clients, it would be necessary to implement some kind of cache wherein
> all of the artifacts have been pre-translated.  That means that the
> storage space requirements on the server would be multiplied by 2 or 3
> (depending on whether your wanted to service just git or just hg or
> both).
>

I assumed a full clone would be far too much. Thus why I was thinking that
non-Fossil VCS clients would be served via shadow repositories, despite
doubling (or more) the repository storage needs.

If a project were so big that the storage requirements became an issue,
then maybe make the shadow repositories be shallow and/or narrow.

(If I'm correctly understanding how git implements branches, it would be
possible to keep the git shadow shallow by periodically deleting old branch
labels/tags (which would allow the referenced commits to be garbage
collected (if not otherwise referenced by other means).)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Ron W]

On Mon, Nov 20, 2017 at 5:22 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Mon, 20 Nov 2017 13:33:11 -0700
> From: Warren Young <war...@etr-usa.com>
> Subject: [fossil-users] Fossil-NG ideas
>
> 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.
>

While I like the idea of a "smart default" for the file name, I'd rather
have an "--open" (or "-o") option to trigger the automatic "fossil open".

1. If the user actually wants to specify the name, the option would be
needed, anyway.

2. By not requiring the option, it would be hiding one of Fossil's
advantages over git and Hg: Multiple working copies without the overhead of
multiple repository copies. (Granted, more likely SVN users migrating to
Fossil will appreciate this, but I know some former git and Hg users that
quickly learned to appreciate this.)

3. Adopting features from git is good, but let's not make Fossil too much
like git.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

OK. My mistake. I misunderstood the post.

Cheers,

Offray


On 20/11/17 18:04, Warren Young wrote:
> On Nov 20, 2017, at 3:41 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
>> On 20/11/17 17:22, Warren Young wrote:
>>> On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas 
>>>  wrote:
 I thought that was the extension
 the shallow cloned repository would get if no extension name was specified.
>>> If you say
>>>
>>>$ fossil clone https://fossil-scm.org fossil
>>>
>>> You get a repository file called “fossil”, not “fossil.fossil”.
>> No. I was referring to the later case (fossil.fossil)
> If you’re simply arguing that .fossil should be appended if a clone file name 
> is given but no extension is given, that’s a separate topic from anything 
> I’ve brought up.  I’m ambivalent about the idea: I’m fine with the current 
> behavior and I wouldn’t be upset if it changed.
>
>>> In my clone-and-open scheme, leaving off the final parameter above would 
>>> give you a directory called “Fossil”
>> Well my argument is related with how I setup the web server to serve
>> files ended in ".fossil", but I can just add more extensions as the
>> community decides.
> I don’t see that clone-and-open impacts that either way.  This feature would 
> be used primarily by people who want to use someone else’s repository.  If 
> they re-serve it at all, it’ll probably be via a bare “fossil server” 
> command, not pointing to a directory of fossils at all or using a front-end 
> proxy layer.
>
> I’m targeting the GitHub use case here: someone publishes a project and 
> people want to just copy the repo contents down into a local directory to 
> mess with, in the fewest steps possible.  Git allows you to do this in 2 
> steps: clone & cd.  Fossil currently requires 5, as I showed up-thread.  
> That’s a problem.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 4:04 PM, Warren Young  wrote:
> 
> Git allows you to do this in 2 steps: clone & cd.  Fossil currently requires 
> 5, as I showed up-thread.

4 steps.  The fifth step in the post starting this thread is part of a separate 
thought.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 3:41 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> On 20/11/17 17:22, Warren Young wrote:
>> On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas 
>>  wrote:
>>> I thought that was the extension
>>> the shallow cloned repository would get if no extension name was specified.
>> If you say
>> 
>>$ fossil clone https://fossil-scm.org fossil
>> 
>> You get a repository file called “fossil”, not “fossil.fossil”.
> 
> No. I was referring to the later case (fossil.fossil)

If you’re simply arguing that .fossil should be appended if a clone file name 
is given but no extension is given, that’s a separate topic from anything I’ve 
brought up.  I’m ambivalent about the idea: I’m fine with the current behavior 
and I wouldn’t be upset if it changed.

>> In my clone-and-open scheme, leaving off the final parameter above would 
>> give you a directory called “Fossil”
> 
> Well my argument is related with how I setup the web server to serve
> files ended in ".fossil", but I can just add more extensions as the
> community decides.

I don’t see that clone-and-open impacts that either way.  This feature would be 
used primarily by people who want to use someone else’s repository.  If they 
re-serve it at all, it’ll probably be via a bare “fossil server” command, not 
pointing to a directory of fossils at all or using a front-end proxy layer.

I’m targeting the GitHub use case here: someone publishes a project and people 
want to just copy the repo contents down into a local directory to mess with, 
in the fewest steps possible.  Git allows you to do this in 2 steps: clone & 
cd.  Fossil currently requires 5, as I showed up-thread.  That’s a problem.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 1:33 PM, Warren Young  wrote:
> 
> 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:

I’ve prototyped this as a simple shell script:



#!/bin/sh -e
url=$1
shift

tmprepo=`mktemp .fslrepo-XX`
rm $tmprepo
fossil clone "$url" $tmprepo

name=`fossil sql -R "$tmprepo" \
"select value from config where name='short-project-name' \
 or name='project-name' and value != '' limit 1"`
if [ -z "$name" ] ; then echo "No project name in $tmprepo!" ;  exit 1 ; fi
if [ -d "$name" ] ; then echo "Already checked out as $name!" ; exit 1 ; fi
if [ -e "$name" ] ; then echo "$name in the way; aborting!" ;   exit 1 ; fi

mkdir "$name"
cd "$name"
mv ../"$tmprepo" .fslrepo
fossil open .fslrepo "$@"



This is not useful as-is, since the whole point of this feature is that 
clone-and-open should be a single step with no other messing about by the user. 
 What it proves, however, is that Fossil has everything needed to do this 
today.  The existing pieces just need to be rearranged to allow it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 17:22, Warren Young wrote:
> On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
>> I thought that was the extension
>> the shallow cloned repository would get if no extension name was specified.
> If you say
>
> $ fossil clone https://fossil-scm.org fossil
>
> You get a repository file called “fossil”, not “fossil.fossil”.

No. I was referring to the later case (fossil.fossil)

>
> In my clone-and-open scheme, leaving off the final parameter above would give 
> you a directory called “Fossil”, since I propose that we reuse the /zip and 
> /tarball option from Admin > Configuration.  Since Fossil’s own repository 
> leaves that option unset, it uses the project name, which is capital-F 
> “Fossil”.
>
> The argument in this sub-thread, then, is what to call the actual repository 
> file.  I’m not wedded to .fslrepo, but it does follow established conventions 
> nicely.  .fslclone could also work, for example, though it would break the 
> 8.3 restriction that Fossil once upon a time held itself to for such critical 
> file names, since the equivalent on Windows would presumably be _fslclone.

Well my argument is related with how I setup the web server to serve
files ended in ".fossil", but I can just add more extensions as the
community decides.

Cheers,

Offray
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 3:12 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> I thought that was the extension
> the shallow cloned repository would get if no extension name was specified.

If you say

$ fossil clone https://fossil-scm.org fossil

You get a repository file called “fossil”, not “fossil.fossil”.

In my clone-and-open scheme, leaving off the final parameter above would give 
you a directory called “Fossil”, since I propose that we reuse the /zip and 
/tarball option from Admin > Configuration.  Since Fossil’s own repository 
leaves that option unset, it uses the project name, which is capital-F “Fossil”.

The argument in this sub-thread, then, is what to call the actual repository 
file.  I’m not wedded to .fslrepo, but it does follow established conventions 
nicely.  .fslclone could also work, for example, though it would break the 8.3 
restriction that Fossil once upon a time held itself to for such critical file 
names, since the equivalent on Windows would presumably be _fslclone.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 17:01, Warren Young wrote:
> On Nov 20, 2017, at 2:55 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
>> On 20/11/17 16:45, Carlo Miron wrote:
>>> On Mon, Nov 20, 2017 at 9:33 PM, Warren Young  wrote:
>>>
 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.
>>> Or maybe `.fossil`, as in Kyle's golang contribution?
>>> https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
>> I would go also with ".fossil" as default extension (is the one I use
>> right now).
> .fossil as an extension for clones is one thing: it is not simply a 
> convention due to “fossil server /DIRECTORY” scanning behavior.
>
> There is no reason the hidden file need follow this convention.  In fact, it 
> would be harmful:
>
> $ fossil server /path/to/clone-and-open/checkout/directory
>
> This would find .fossil and require that you pass an empty name in the clone 
> URL.  Confusing and maybe not even possible, since http://localhost:8080 and 
> http://localhost:8080/ are normally treated as equivalent.
>
> Furthermore, we already have .fsl* at the root of a checkout.  Shouldn’t we 
> follow the existing convention?

OK. I didn't understand this totally. I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

Cheers,

Offray
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 2:55 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> On 20/11/17 16:45, Carlo Miron wrote:
>> On Mon, Nov 20, 2017 at 9:33 PM, Warren Young  wrote:
>> 
>>> 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.
>> Or maybe `.fossil`, as in Kyle's golang contribution?
>> https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
> 
> I would go also with ".fossil" as default extension (is the one I use
> right now).

.fossil as an extension for clones is one thing: it is not simply a convention 
due to “fossil server /DIRECTORY” scanning behavior.

There is no reason the hidden file need follow this convention.  In fact, it 
would be harmful:

$ fossil server /path/to/clone-and-open/checkout/directory

This would find .fossil and require that you pass an empty name in the clone 
URL.  Confusing and maybe not even possible, since http://localhost:8080 and 
http://localhost:8080/ are normally treated as equivalent.

Furthermore, we already have .fsl* at the root of a checkout.  Shouldn’t we 
follow the existing convention?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Offray Vladimir Luna Cárdenas]

On 20/11/17 16:45, Carlo Miron wrote:
> On Mon, Nov 20, 2017 at 9:33 PM, Warren Young  wrote:
>
>
>> 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.
> Or maybe `.fossil`, as in Kyle's golang contribution?
> https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
>
> ㎝
>

I would go also with ".fossil" as default extension (is the one I use
right now).

Cheers,

Offray
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG ideas

[Warren Young]

On Nov 20, 2017, at 1:33 PM, Warren Young  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 releasehttps://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

Re: [fossil-users] Fossil-NG ideas

[Carlo Miron]

On Mon, Nov 20, 2017 at 9:33 PM, Warren Young  wrote:


> 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.

Or maybe `.fossil`, as in Kyle's golang contribution?
https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fossil-NG ideas

[Warren Young]

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