Just to contribute my 2 cents to this discussion, for our workflow I'd find sparse clones much more useful than shallow ones, although I can see how deep history can slow initial clone, and that past certain point is rarely useful.
It's not our problem - but we have thousands of separate source files in modules that are directory subtrees. Yes, we split those in different Fossil repos, but this approach introduces dependencies and repo management overheads. It's easier to have a single encompassing repo than 30 separate ones, especially if documentation and tickets are involved. There is also IP protection aspect. Being able to clone a certain directory only from the source tree would allow us to restrict the third party developers to see just what they are supposed to see and are allowed to work on. From that perspective sparse clones would have to be 'special' in a sense that you can't sync fully on demand afterwards. This probably means special privilege with list of directory globs an user is allowed to clone sparsely. I am not quite sure how would it all work in Fossil though. The sparse clone from a dir would have to fetch all the check-ins that contain changes to affected files, but drop the other artifacts outside the dir. I suppose we could have missing artifact warnings on update/status/diff (similar to current missing common ancestor warnings in certain merge scenarios), but it will be nice if Fossil is aware that repo is a special sparsely cloned one, and interpret those missing artifacts by showing (or hiding, if preferred) appropriate warnings to avoid confusion. Finally, there is a question of wikis and tickets. Following this model sparse clone would not fetch them, but perhaps it is more useful if this is governed by existing user wiki/ticket privileges. S. Original Message From: Warren Young Sent: Tuesday, 7 February 2017 10:58 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Git just got shallow and sparse clones On Feb 6, 2017, at 4:49 PM, Warren Young <[email protected]> wrote: > >> allow cloning a repository “shallowly" > > That’s not what I mean by “shallow,” since according to the docs,[1] Oh, I see the --no-single-branch bit now. Sigh, another confusing Git default. Even so, it still doesn’t quite do what I want: - I want to give --depth in days, not checkins. - I want to allow the cloned-from repository to set a sensible default, so that very large repos can require that cloners specify something like --deep to get everything. Personally, I don’t need this for my own repositories. I’m just putting out ideas to handle extremely large repos. As for my second point above, I’d have been happy if the Linux kernel source repo I checked out onto a Raspberry Pi had only given me the past 30 days or so, without me having to know about --depth. I only wanted --depth=1 anyway. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
