Re: [fossil-users] Multiple independent timelines in a fossil - how to create and what are the unintended consequences?
2014/1/12 Matt Welland estifo...@gmail.com: 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. In stead of removing the initial commit, there is another way to add multiple initial checkin's, but you have to modify the local checkout (the .fossil or _FOSSIL_ file) manually using the sqlite3 utility: sqlite3 .fossil sqlite3 UPDATE vvar SET value=0 WHERE name='checkout'; sqlite3 DELETE from vmerge; sqlite3 DELETE from vfile; sqlite3 .exit fossil commit --branch branch ... The last command creates a new 'initial' commit with whatever properties you like. This looks more dangerous than it actually is: The .fossil file keeps track of the current checkout, so it is impossible to corrupt the actual repository, at most you could corrupt your local checkout. But since you want to start with a fresh checkout anyway, that's whats happening here .. I would expect that the following command: fossil update rid:0 would have the same effect, but that doesn't work. It's easy to fix, but since fossil still contains panic's in various places when rid==0 not all commands will work. It's still considered experimental. 2014/1/12 Matt Welland estifo...@gmail.com: 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? I don't think anything will break. Fossil cannot handle rid=0 checkouts in all commands (yet), but commit works fine and after the first commit you don't have an rid=0 checkout any more. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Multiple independent timelines in a fossil - how to create and what are the unintended consequences?
On Mon, Jan 13, 2014 at 10:56 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: sqlite3 .fossil sqlite3 UPDATE vvar SET value=0 WHERE name='checkout'; sqlite3 DELETE from vmerge; sqlite3 DELETE from vfile; sqlite3 .exit fossil commit --branch branch ... Tricky, tricky! i think that approach might find a home in libfossil's API at some point. I don't think anything will break. Fossil cannot handle rid=0 checkouts in all commands (yet), but commit works fine and after the first commit you don't have an rid=0 checkout any more. FYI: rid==0 has a long history as the sentinel not-an-RID placeholder because the auto-increment mechanism ensures that any inserted RID is always positive. That said, based on this thread there would appear to be some interesting uses for using rid:0 as a special case in some routines. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Multiple independent timelines in a fossil - how to create and what are the unintended consequences?
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. 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. 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
Re: [fossil-users] Multiple independent timelines in a fossil - how to create and what are the unintended consequences?
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
