On Sun, Jan 12, 2014 at 12:01 PM, Richard Hipp <d...@sqlite.org> wrote:
> > > > On Sun, Jan 12, 2014 at 1:06 PM, Matt Welland <estifo...@gmail.com> wrote: > >> I find myself wanting to maintain multiple fossils per project since some >> parts need to decoupled from the source. This is a pain since now I have to >> remember to sync multiple fossils, >> > > The "fossil all sync" command should mitigate this pain somewhat. This > will sync all your projects, even those that are unrelated. I find it very > useful when I'm leaving on a trip to "fossil all push" on my desktop then > "fossil all pull" on my laptop, thus ensuring that I have everything with > me. > > The "fossil all changes" command is also available, for identifying those > repos that need a commit. > Yes, these and the login group stuff do make it easier. Because I've done so many experiments with fossil using ssh and other things I get a little nervous when I do global actions that something unintended might happen and so I tend to avoid it. Nonetheless, a very good point. > > > >> deal with N times the maintenance (e.g. add users to three fossils) >> > > > You can add multiple repos to the same "Login Group" under the Admin menu > to get single-signin. You still have to add users to each repo separately, > but once added, users can change their passwords on all repos in a single > go, and they only have to login to one repo in order to get access to them > all. If you already have all users on one repo, you can transfer them all > to another repo easily using > > fossil config export user -R 1strepo.fsl - | fossil config import -R > 2ndrepo.fsl > > >> and wiki pages and tickets are not shared. >> >> I find that documentation, configuration and tests work better for me >> when not coupled directly to the source timeline (i). I can achieve this by >> branching from the first node and then maintaining the purpose branches but >> this leaves open the risk of accidentally merging these branches that >> should never merge to trunk, an irreversible action. >> >> I've accidentally created independent timelines in fossil before when >> importing from monotone so I know it can be done (or used to be possible). >> Is there a way to do this either with the official fossil binary or with a >> little sql hackery? What things are likely to break if I go down this path? >> > > Maybe (haven't actually tried this) you could create a branch called "doc" > then create a second check-in on the doc branch, then shun the original doc > check-in and rebuild. That might prevent the doc branch from ever being > merged with any other. Try this on test repo first. Maybe share your > results with the mailing list. If it works, maybe we'll add it to the > official docs someplace. > > The other thing you might try is to take two or more independent repos and > run "fossil deconstruct" on them all, to generate directories filled with > artifacts. Then combine the artifacts from all deconstructions into a > single directory. Then "fossil reconstruct" a new repository from the > combined directory. One problem with that approach is that you would > likely end up with multiple disjoint branches named "trunk". To fix that, > just find the first check-in for each of the multiple "trunk" branches (or > maybe all but one of them) and rename that first check-in using the "Make > this check-in the start of a new branch" option on the "edit" webpage. > I've tested both these ideas and they appear to work. It does look like shunning or removing the initial commit is needed or somehow the code sees a connection between the trees. In my test half the files had no ancestor and did not merge and half the files did merge as "ADDED". I don't see the pattern but by removing the initial commit this didn't happen. I'll test this out for a while and report back to the list in case the idea is of use to anyone else. Thanks for the input, it was much appreciated. > >> In my dream version of fossil it would be possible to have top-level >> directories associated with different timelines and then be able to >> configure a contour. E.g. >> >> src - branch-v1.55 >> docs - tip >> tests - tip >> >> For now I'd just be very happy if I could create the docs and tests as >> branches with no ancestor in common with src. I will then open each in a >> separate sub dir something like this: >> >> cd src;fossil open ~/fossils/project.fossil;fossil co trunk >> cd ../docs;fossil open ~/fossils/project.fossil;fossil co docs >> cd ../tests;fossil open ~/fossils/project.fossil;fossil co tests >> >> -project-|-src >> |-docs >> |-tests >> >> (i) The reason for separate timelines for documentation, tests and >> configuration is that in each one of these cases I sometimes need to work >> with different combinations or contours. The most common example is running >> the latest tests against older versions. The scenario goes like this; a bug >> is found and the tests are updated and then go back to fix an officially >> released version but since the tests are tightly coupled with the source it >> requires removing directories and symlinking to a different checkout which >> is error prone and ugly. >> -- >> Matt >> -=- >> 90% of the nations wealth is held by 2% of the people. Bummer to be in >> the majority... >> >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority...
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
