> So I thought that might have meant multiple, distinct trees, similar to > how one can have branches in Git with independent directory structures > but all separate from each other, even if they are stored in the same > repository. > > I'm wondering how difficult/desirable it might be to support a case like > the one I mentioned? Maybe you could have a single repository with > multiple roots, and do something like: > > mkdir project_a; cd project_a; fossil open ../myproj.fossil project_a > cd ..; mkdir project_b;... > > Or maybe some means of opening a project's subdirectory such that open > with normal parameters would copy out all subdirectories/projects while > "open myproj.fossil src" might only extract the src directory, but that > may be entirely impractical.
I think what you are after is what I asked about in a thread "Projects Structuring" a few days ago (24 August 2010). Here's my situation (that I think is similar to yours)… You have a number of projects that have their own files, but they also share a "library" of files. You would like to develop the projects independently. Ideally, they need to have their own version of the library: you may make an update to one project that requires updates to the library, but you may not be ready to merge those library updates in to all other projects. In addition, you perhaps have branches of each project that you are working on: a few recent builds, the current release, a beta test, and the development trunk. I don't believe that there is an established way to do this with fossil (but please correct me if I'm wrong!). If your projects and library are not too huge, then a perfectly good approach might be to simply use a single fossil repository for all of your projects and also for the library. You can then open copies of this to your heart's content. If your projects are "large" then this will become extremely redundant (lots of wasted disk space, and lots of files to check when doing fossil operations), which might be, or later become, a problem for you. In Perforce (another version control system), the approach taken is to have a single repository. Perforce has a feature called (I think) a "View Spec." (or view specification) that essentially lets you control which bits of the repository are checked out in to a particular working copy, thus avoiding the redundancy that I mentioned this approach can introduce. I've used fossil for a while but I'm by no means an expert, so apologies if I'm creating more confusion! Thanks, Benjohn -- [email protected] - Twitter @benjohnbarnes - Skype benjohnbarnes - Mobile +44 (0) 7968 851 636 _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
