On Mar 2, 2015, at 5:30 AM, Richard Hipp <d...@sqlite.org> wrote: > > The key idea would be to relax the requirement that each client load > the entire history of the project. Instead, a clone would only load a > limited amount of history (a month, a year, perhaps even just the most > recent check-in).
This would be wonderful! I would suggest a refinement on the simple “SELECT * WHERE modification_date < 1month” idea, though: I actually want the past month (or whatever) of history on *each* open branch relative to the date of the checkin time on the tip of that branch. That is, if I last changed the “v8” branch two years ago, I still expect it to give me a month’s worth of file info on that branch. I need it if I am going to do tech support on that branch: “v10 does thus-and-such when you press the Foobie button, but v8 behaves differently. Can you look into the code to find out why?” I also need it if I’m going to backport a fix to v8 from v10. I’m thinking this should be the default behavior, at least by configuration at the master repo level. It should take extra flags to get a complete clone. This is a break with existing practice, but Pollack’s right: it’s rare for me to actually need deep history on every branch. The longest I typically need history for is however long it’s been since the last release on that branch. If I get this feature, it’s going to make me want another one, though: the ability to merge two repositories. For one of my several svn repos which I converted to Fossil, I purposely checked in only the tip of the svn trunk into a fresh repo, rather than convert a decade of history. I did it for the reason Pollack points out in the article: faster checkins and other tree traversals. If I need to go back into the pre-Fossil history, I have a separate svn-to-Fossil conversion repo. If Fossil’s speed becomes independent of the depth of the checkin history, I’d like the ability to make those two into a single repo, since the *effect* of a clone will then be more like my current setup, where there are relatively few checkins, and none of the blobs have forks in their history yet. I realize I can probably do that by hand with some kind of export-and-reimport via the Git fast-export path, but I’d like to do it entirely within Fossil, if possible. > For "wide" repositories (such as bsd-src) that hold many thousands of > files in a single check-out, Fossil could be enhanced to allow > cloning, checkout, and commit of just a small slice of the entire > tree. This would also be awesome. I miss that from Subversion. Those of us who have converted from Subversion often have trees that depend on the ability to check out just a slice of the tree. I had only one Subversion repo at home, with everything “versionable” stored in it. I could then check out different chunks of the tree, placing each where I wanted that working subtree to live. If I were creating such a system fresh in Fossil today, I’d create separate Fossil repos for each different sub-tree of files. Not because this is what *I* need, but because this is what *Fossil* expects. I’m currently hacking around this by checking the monolithic repo out into a hidden location, then creating symlinks back into subfolders of that checkout. Yes, ick. I’ve considered reconverting the repo, using Git’s ability to rewrite history and thereby slice the repo up, but that’s just more work than it’s worth to me. What I really want is what you propose: Subversion-like subrepo checkouts. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
