D. Richard Hipp wrote: > mkdir libA mylibA libB > cd libA; fossil open ../libAB.fossil libA; cd .. > cd mylibA; fossil open ../libAB.fossil mylibA; cd .. > cd libB; fossil open ../libAB.fossil libB; cd .. > > Now you have three subdirectories, each containing the latest code for > one of your branches. Thanks :) I have also subsequently found http://www.sqlite.org/privatebranch.html which is detailed and quite helpful.
I feared the answer may be something along these lines. It is also the approach suggested for bzr, hg, and others. It solves my problem in this particular case, but not in a more general case -- and it would appear to force a choice I'd rather not have to take (c'est la vie). Let me present another case: I have a custom Tcl shell. To maintain it I need to update to the core distributions of tcl, tk, and threads every so often. I also have to maintain some patches against the tcl and threads trees, and occasionally some fixes that haven't yet gone through the bug system and made it into the upstream repository. Then there is an experimental Tcl extension that uses CMake as its build system rather than GNU autotools. Add in a couple of pure Tcl libraries and code snippets, some C utilities, a half dozen HOWTO documents, some overview information and license policies. My plan is to use Fossil to synchronise all of this between various PCs, and to make it available on my web site under an OSS license. So, as I understand it, these are my options: (a) Put everything in one repository. Advantages: simple - one repo to commit/update/sync; I can see all my personal projects in one timeline (really useful). Disadvantages: branches span logically separate projects; in the filesystem each branch contains all the projects (b) Put each project into a separate repository. Advantages: more obvious workflow when using branches (for vendor drops, stable/development branches, or developing multiple features in parallel) Disadvantages: need to commit/update/sync multiple repos; no single view of all development effort; extra effort to set up an maintain overview docs and OSS license policies for each repo; new code trees require a new repository which involves setting up the repository and appropriate scripts/redirects on my web site. There appears to be no compromise. (a) reduces the effort of managing the source control environment, which gives me more time to work on projects and less incentive to waste time finding a source control system that gets in my way less (which is pretty much what I'm doing now). (b) lets me handle some of the more complex source control tasks, which I need to handle because I am tracking third party sources. git, bzr and hg all seem to have workarounds for this - forests of repositories, partial checkouts, shelving changes to avoid an extra branch/clone, etc. Is this "choice" I am facing a "weakness" of the DVCS model in general, requiring a radical change in workflow or one or the aforementioned workarounds -- or am I missing some other obvious approach? If the "weakness" is indeed general, I would be interested in comments on a hypothetical option (c): (c) Put everything in one repository, and extend "open" to support a subtree of a branch: fossil open my.repo ?version? ?subtree? Only the files below _subtree_ will be retrieved into the filesystem, and they will be retrieved into the local root (instead of root/subtree). In effect a partial tree checkout. By way of example, if I have the following files in my repository: /readme.txt /project_a/source.c /project_a/source.h /project_b/main.c /project_b/res/data.txt Then I open a subtree using "fossil open my.repo trunk project_b" ... I will get the following in my current directory: /main.c /res/data.txt /_FOSSIL_ update, commit, checkout, diff, changes, extras, etc. will operate as expected. branch/merge will (as usual) operate on the entire branch in the repository, not just the portion visible in the filesystem. Thanks again for all the help, Twylite _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
