i've also tried to get this to work, but fossil has some issues with checking out multiple repositories to the same working folder/subfolder..
i haven't tried recently with the new ignore options, so it may be possible now, but I suspect it would take a bit of mucking around.. On 24/08/2010 6:29 PM, Benjohn Barnes wrote: > Hi, > > My current practice is to have a fossil repo per project. I've committed the > (cardinal) sin of duplicating shared files between projects. I want to fix > this. > > Conceptually I'd like to have one huge repo for everything (individual > projects and all common files), and maintain working copies of this (per > active project branch), but it seems like this would be slow and redundant > (unless I can mark a working copy as not needing most sub folders of the full > repo). > > So, my thought is that I should have a number of per project repository, and > a single common repository for shared files. I'm going to talk through the > structure I think I'll go for, and I'm interested to hear if anyone's got > guidance or comments. > > The shared repo is likely to be used at different versions by different > projects - presumably I can use branches and tags where necessary to have a > project get hold of the version of common stuff that it needs. Does anyone > have any neat way to get this happening fairly automatically; storing the > branch / version of the common files that a particular branch / version of a > project requires? I can probably cook up some Ruby to automate this, but do > people have suggestions about what I should be automating? :-) > > How should I actually structure my working copies? Each working copy should > probably have its own working copy of the common files. It seems to make > sense that the working copy folders are like this: > > Project Folder - not under version control > Build files and artefacts - not under version control > Shared Files Working Copy - under version control > Project Files Working Copy - under version control > > Sorry if I've missed a well known resource discussing a good approach or > approaches. It's quite possible my thinking is wrong headed; it's roughly the > kind of thing I'd have done with CVS so it may not make sense with fossil. > Please let me know if I'm being dumb and taking on unnecessary complexity! > > Incidentally – for the most part I'm expecting to be working solo on > projects, but it would be nice to have an approach that is workable with a > small team. > > Thanks very much, > Benjohn > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
