If I get your script right, then I would have one fossil repository for each sub-project and one for the top-project. So with nested repositories my administration overhead would exceed even the single repository solution, right?
Johan Kuuse <jo...@kuu.se> schrieb am Sa., 12. Sep. 2015 um 16:27 Uhr: > Hi, > > After some suggestions in this ML, I chose using nested repositories. > The "root repository", which I called 'nested', only contains a few files. > All other repositories are open inside the 'nested' directory, with the > -nested option. > > Here is a script which clones, opens and updates the entire nested > directory tree (fossul-setuo.sh): > > http://kuu.se/fossil/nested.cgi/doc/tip/index.html > > Just my two cents to give you an idea... > > BR, > Johan > El 12/9/2015 14:44, "Michai Ramakers" <m.ramak...@gmail.com> escribió: > >> Hello, >> >> On 12 September 2015 at 14:34, Oliver Friedrich >> <redtalonof+mailingl...@gmail.com> wrote: >> > I want to give a thought on how I use fossil regularly and on what I >> would >> > love as a feature. >> > >> > While fossil is easy to set up and maintain, I often have several small >> > projects that seem to be to small to get an own instance of a >> repository for >> > themselfes. Additionally, I like to use fossil, because it reduces the >> > number of files to manage (1 repo instead of dozens of files per >> project). >> > >> > That spoken, I have bunch of code-samples and abstracted code-problems >> in >> > different programming languages and flavours, that I keep as personal >> > knowledge database. I tend to give each of them its own fossil >> repository, >> > but as I mentioned before, sometimes they have just one or two files. >> > >> > My old solution was to have one repository with one set of folders for >> each >> > sub-project. But Timeline get messy really fast and it is hard to track >> > sub-projects with this approach. >> > >> > My current solution is to have one repository with an empty initial >> check-in >> > tagged as ROOT. Then I do one branch per sub-project based on the ROOT >> > check-in. >> > >> > That way I'm able to keep my code cleanly detached from each another, >> but it >> > feels really dirty - cause that's in no way the correct handling of >> > branches. >> > >> > What I really would like to have is to gather multiple such small >> projects >> > in one repo file, so instead of having one ROOT check-in, having one >> ROOT >> > for each project. I know that would make developing fossil a bit >> harder, but >> > I think it would be a great feature and that not I'm the only one who >> would >> > use this. >> > >> > In the simpliest logic I can imagine this would mean nothing more than >> one >> > additional layer, branches belong to project. For the normal use, each >> > branch would just belong to the default project. But I guess that >> > implementing this could be much harder, especially visualizations in the >> > web-frontend. >> > >> > But what do you think about multiple projects in one repo? >> > What would be your approach on my problem? >> >> I think this has come up a few times on this ML; I think some >> suggestions are to use nested repos ('fossil open --nested') or >> indeed, branches. At least one post about disjoint timelines within a >> project is here: >> http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983 >> >> I happen to use branches, just like you, and am fairly happy with >> this. Nested repos were a bit overkill for me, but I guess that's >> personal. >> >> Michai >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
