Re: [fossil-users] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov slonik...@gmail.com wrote: I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? If i'm not sorely mistaken, fossil was indeed originally designed for exactly one purpose: managing the sqlite repo. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] how to maintain a set of patches?
On Sat, 25 Feb 2012 15:48:10 -0500 Leo Razoumov slonik...@gmail.com wrote: I hope that you realize that one size fits all is not a good design principle for a general purpose tool. /me nods And yes, I do need my private space for private experimentation. For instance I keep some branches where code does not yet compile. But the branches that I push to TEAM.fossil should pass a red face test, they should at least compile OK. I also find reasonable not to clutter team members' repos with my half-baked experiments. I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? Yeah...Fossil is very refreshing tool, beating many apps by its simplicity, but Everything should be made as simple as possible, but not one bit simpler. Sincerely, Gour -- The embodied soul may be restricted from sense enjoyment, though the taste for sense objects remains. But, ceasing such engagements by experiencing a higher taste, he is fixed in consciousness. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] how to maintain a set of patches?
On Sun, Feb 26, 2012 at 04:48, Stephan Beal sgb...@googlemail.com wrote: On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov slonik...@gmail.com wrote: I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? If i'm not sorely mistaken, fossil was indeed originally designed for exactly one purpose: managing the sqlite repo. GIT was originally designed as a BitKeeper replacement for linux kernel. Then the scope broadens... --Leo-- ___ 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] how to maintain a set of patches?
On Feb 26, 2012, at 15:00 , Leo Razoumov wrote: On Sun, Feb 26, 2012 at 04:48, Stephan Beal sgb...@googlemail.com wrote: On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov slonik...@gmail.com wrote: I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? If i'm not sorely mistaken, fossil was indeed originally designed for exactly one purpose: managing the sqlite repo. GIT was originally designed as a BitKeeper replacement for linux kernel. Then the scope broadens... Well, IIRC Mercurial was even more narrow, originally created to keep only some subsystem of the kernel ;) Kind regards, Remigiusz Modrzejewski ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 02:26, Gour g...@atmarama.net wrote: On Fri, 24 Feb 2012 18:13:15 -0500 Leo Razoumov slonik...@gmail.com wrote: One thing that I miss in fossil above everything else is inability to push/pull individual branches or/and individual artifacts. This is really big item on my wish list. Current fossil model has only two choices: public branches that are accessible to all, and private branches that are for-your-eyes-only. Afaik, it's possible to push private branches as well, but, I agree, Fossil is mostly 'all or nothing'. Yes, you can push *all* private branches with fossil push --private. Again, it is all or nothing proposition. In my workflow I need to push few select branches to a remote repo. For the most part I use private branches as for-my-eyes-only throw away temporaries which are cleansed with fossil scrub. Recently Brian Smith announced on this list that he is working on limsync fossil extension that allows to push/pull individual branches. http://code.linuxfood.net/pub/repo/fossil-limsync The code is still experimental and has some issues but hopefully it will stabilize soon. --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 2:26 AM, Gour g...@atmarama.net wrote: Right. I'd like to have simple 'rollback' as well in a situation when I quickly find out that the commit was simply mistake... A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. If an error is found, you annotate the erroneous entry with a note of correction and/or create new entries to undo the mistake. You do not erase or alter existing entries. And in this way one maintains an audit trail. Other VCSes allow you to edit the DAG. (The rebase command of git is the prime example.) That's OK for git because their philosophy is that the DAG is part of the project documentation and should be clean and neat. The Fossil philosophy, in contrast, is that the DAG should be a true and accurate history what you really did, rather than what you should have done. So the git-way of handling a mistaken commit would be to roll it back. The Fossil-way would be to tag that commit as being the beginning of a new branch, typically a branch named mistake, and then close the branch. You can see examples of the Fossil-way, here: http://www.fossil-scm.org/fossil/timeline?c=2011-06-16+18%3A10%3A54n=6 http://www.sqlite.org/src/timeline?r=mistake That said, I'm not completely opposed to having the ability to back out a mistaken commit, so long as that commit has not been pushed or synced to other repositories. It is DAG editing (rewriting history) that I am opposed to. Rewriting history (rebase) and omitting parts of history (rolling back commits) are distinct concepts, and rewriting (lying) is clearly a greater sin than omitting irrelevancies. But most Fossil users operate in autocommit mode, meaning that commit and push happen together, so there is seldom exist any unsynced commits, which is perhaps the biggest reason why rollback has never been implemented. For contributing to Fossil itself, there is a Pre-checkin Checklisthttp://www.fossil-scm.org/fossil/doc/trunk/www/checkin.wikithat developers are suppose to follow prior to each 'fossil commit. (A similar checklist exists for SQLite.) A key element of this checklist is the fossil diff - to make sure you really know what you are about to check in. Very often I spot debugging statements that should have been removed, missing or erroneous comments, bad indentation, or goofy variable names during that fossil diff step, and thus have an opportunity to correct those errors prior to making them a part of the permanent record. I also find that I am able to write better checkin comments if I have just reviewed all changes associated with the checkin. I highly recommend that you adopt some kind of short, simple pre-checkin checklist for your projects as well, and that this checklist involve a diff of what is about to be checked in. It really does help. -- 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 09:17, Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. I am fine with this philosophy of no-rewriting of published history. And I am *not* asking for a git rebase equivalent. But I have to follow a work-flow that consists of a cascade of repositories. (1) PRV.fossil -- is my private repo where all my dirty laundry is stored (2) TEAM.fossil -- this is a place shared by the development team. Mistakes can be annotated as mistake and backed out as you said. (3) PUBLIC.fossil -- is a clean and shiny final result that must be devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. So far I found no way to accomodate (1)-(2)-(3) cascading work-flow. Please, advice if I am missing something (I am a novice fossil user). Previous discussions on this list suggested a new feature [1] that would allow to push/pull individual leaves or branches. If implemented it would resolve my biggest grievance with fossil. [1] http://code.linuxfood.net/pub/repo/fossil-limsync --Leo-- ___ 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] how to maintain a set of patches?
On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote: On Sat, Feb 25, 2012 at 09:17, Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. I am fine with this philosophy of no-rewriting of published history. And I am *not* asking for a git rebase equivalent. But I have to follow a work-flow that consists of a cascade of repositories. have to? Why? Is this a case of having to step back and look at the aim of the workflow rather than assuming that it is set in stone? (1) PRV.fossil -- is my private repo where all my dirty laundry is stored Do you need a repository for this? A repository is not a backup tool. (2) TEAM.fossil -- this is a place shared by the development team. Mistakes can be annotated as mistake and backed out as you said. (3) PUBLIC.fossil -- is a clean and shiny final result that must be devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. Why do you need (3)? Who are you hiding stuff from? I think a clean branch is all you need. Actually I think most of your issues can be dealt with by suitable use of branches. To go back to your earlier example, if P2 has nothing to do with P1 it should probably have been in a branch of its own. Which reminds me that I was going to say earlier that I don't understand the emphasis on patches. A patch is just a way of transforming one version of a file into another version, and is not a necessary component of an SCM system. Eric -- ms fnd in a lbry ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 14:19, Eric e...@deptj.eu wrote: On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote: I am fine with this philosophy of no-rewriting of published history. And I am *not* asking for a git rebase equivalent. But I have to follow a work-flow that consists of a cascade of repositories. have to? Why? Is this a case of having to step back and look at the aim of the workflow rather than assuming that it is set in stone? Eric, I hope that you realize that one size fits all is not a good design principle for a general purpose tool. (1) PRV.fossil -- is my private repo where all my dirty laundry is stored Do you need a repository for this? A repository is not a backup tool. I never mentioned backup, did I? And yes, I do need my private space for private experimentation. For instance I keep some branches where code does not yet compile. But the branches that I push to TEAM.fossil should pass a red face test, they should at least compile OK. (2) TEAM.fossil -- this is a place shared by the development team. Mistakes can be annotated as mistake and backed out as you said. (3) PUBLIC.fossil -- is a clean and shiny final result that must be devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. Why do you need (3)? Who are you hiding stuff from? I think a clean branch is all you need. First and for most, this project is company internal. But some versions are exported outside to our external collaborators. For variety of reasons that are beyond of my control MY.fossil, TEAM.fossil and PUBLIC.fossil have to be separate. As a new fossil user I posted a question to this list on how can I establish cascading work-flow using fossil. I would appreciate if someone could tell me whether it is possible or not. I am looking for a tool that helps me and my team to do the work in my environment. I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 09:17:57AM -0500, Richard Hipp wrote: For contributing to Fossil itself, there is a Pre-checkin Checklist that developers are suppose to follow prior to each 'fossil commit. (A similar checklist exists for SQLite.) A key element of this checklist is the fossil diff - to make sure you really know what you are about to check in. Very often I spot debugging statements that should have been removed, missing or erroneous comments, bad indentation, or goofy variable names during that fossil diff step, and thus have an opportunity to correct those errors prior to making them a part of the permanent record. I also find that I am able to write better checkin comments if I have just reviewed all changes associated with the checkin. I highly recommend that you adopt some kind of short, simple pre-checkin checklist for your projects as well, and that this checklist involve a diff of what is about to be checked in. It really does help. Is the 'pre-checkin checklist' for fossil and sqlite publicly documented somewhere? This sounds like a good development habit to get into and it would be nice to maybe have a template to start from. -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ 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] how to maintain a set of patches?
On Sat, 25 Feb 2012 06:48:59 -0500 Leo Razoumov slonik...@gmail.com wrote: For the most part I use private branches as for-my-eyes-only throw away temporaries which are cleansed with fossil scrub. Heh today after more detailed reading of the docs, I've 'found out' that fossil scrub --private might be good enough as replacing hg's MQ extension...Was absent the whole day and will try tomorrow. Recently Brian Smith announced on this list that he is working on limsync fossil extension that allows to push/pull individual branches. http://code.linuxfood.net/pub/repo/fossil-limsync The code is still experimental and has some issues but hopefully it will stabilize soon. That would be *very* nice thing. Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 18:17, Gour g...@atmarama.net wrote: Heh today after more detailed reading of the docs, I've 'found out' that fossil scrub --private might be good enough as replacing hg's MQ extension...Was absent the whole day and will try tomorrow. Be aware that fossil scrub --private will remove *ALL* your private branches including the ones you created for some other purposes. --Leo-- ___ 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] how to maintain a set of patches?
On Sat, 25 Feb 2012 09:17:57 -0500 Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. If an error is found, you annotate the erroneous entry with a note of correction and/or create new entries to undo the mistake. You do not erase or alter existing entries. And in this way one maintains an audit trail. That's clear. That said, I'm not completely opposed to having the ability to back out a mistaken commit, so long as that commit has not been pushed or synced to other repositories. This is very inspiring to hear. Darcs is my 1st DVCS and very early I had to learn the lesson that rollback is useful only as long as the pathes haven't escaped out in the wild. It is DAG editing (rewriting history) that I am opposed to. Here I fully agree with you. Rewriting history (rebase) and omitting parts of history (rolling back commits) are distinct concepts, and rewriting (lying) is clearly a greater sin than omitting irrelevancies. Although there is rebase for Mercurial I am not at all thinking about using it 'cause having 'unfinished' patches handled by MQ and commiting them when ready is also what we need...although latest Mercurial did get 'phases support' feature which is touched by Leo in 'feature proposal: explicitly public branches' thread. But most Fossil users operate in autocommit mode, meaning that commit and push happen together, so there is seldom exist any unsynced commits, which is perhaps the biggest reason why rollback has never been implemented. Well, I expect from the nicely crafted tool to allow me to circumvent its default route of operation by transferring responsibilities for the action to me. So, if you implement rollback and I do something stupid, I promise here that, unlike Zed, I won't neither blame you nor Fossil. ;) Sincerely, Gour -- A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 09:17, Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. If an error is found, you annotate the erroneous entry with a note of correction and/or create new entries to undo the mistake. You do not erase or alter existing entries. And in this way one maintains an audit trail. I agree that the concept of non-rewritable history in a given repository is a good thing. But it should not preclude ability to export a subset of history (a fully connected component of the original DAG) as a separate repository (might be even with a different project-ID). If I have a book History of the World I should be able to take a chapter on American History and publish it as a book History of the USA. --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 24, 2012 at 02:53, Gour g...@atmarama.net wrote: On Fri, 10 Feb 2012 15:46:15 -0500 Leo Razoumov slonik...@gmail.com wrote: I am sorry if my language was not clear. Here are the diagrams: I am sorry to jump in this thread...we might soon start working on our application which is meant for niche market and therefore potential contributors although experts in the field are probably not savvy with DVCS tools, so Fossil is definitely unprecedented wiht its features and simplicity to setup use. Otoh, we're familiar with DVCS tools (starting from darcs, bzr, mtn) and now being hg user would like to not to lose any functionality from e.g. hg. My question is connected with Mercurial's MQ feature... Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Let's assume I've the same situation like above, but consider that my patches are too granular to commit each one to the trunk and would like to eg. combine P1 P3 together and then apply them as: P2' -- P1_P3' to my trunk. Is it possible to do it in Fossil? In git --rebase it is known as patch squashing. Could you, try the following (untested) fossil update E fossil merge --cherrypick P1 fossil merge --cherrypick P2 fossil merge --cherrypick P3 fossil commit --tag P1-P3.squashed If the code above does not work you can try poor-man's approach with the patch (untested) fossil co E fossil diff --from P1-parent --to P3 | patch Please, be aware that patch method does not handle addition/removal of the files. --Leo-- P.S. Maintaining patch sets, squashing/folding are everyday tasks in many popular work-flows. It would be great if fossil supports them natively rather that via ugly hacks. ___ 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] how to maintain a set of patches?
On Fri, 24 Feb 2012 08:55:09 -0500 Leo Razoumov slonik...@gmail.com wrote: In git --rebase it is known as patch squashing. I'm not familiar with git... Could you, try the following (untested) fossil update E fossil merge --cherrypick P1 fossil merge --cherrypick P2 fossil merge --cherrypick P3 fossil commit --tag P1-P3.squashed I should produce better test case, but it could kind of work...although it's not very pretty. The point is that both hg git have 'staging area' (fomer in the form of MQ), so when one does with the patches, can cleanly apply them and get rid of the patch queue. Otoh, Fossil is, by design, quite 'unforgiving' when it comes to putting mistakes 'under the rug'. Maybe, for the above example it would be better to toss patches by using stashes, but I've to experiment with it if it could provide better workflow. If the code above does not work you can try poor-man's approach with the patch (untested) fossil co E fossil diff --from P1-parent --to P3 | patch  Please, be aware that patch method does not handle addition/removal of the files. Yeah, that's not pretty and I'd like to leave such job to Fossil itself. P.S. Maintaining patch sets, squashing/folding are everyday tasks in many popular work-flows. It would be great if fossil supports them natively rather that via ugly hacks. I fully agree with it. ;) Btw, may I ask you do you miss something else in Fossil as (possibly) ex-hg user? New Mercurial has brought interesting concepts of phases...still, I have to experiment a bit more (again) with Fossil before deciding that to use for our upcoming open-source project which we might tackle soon. Iirc, there was statement by Richard that he made 'rename' workable, but too cumbersome, but I see that Fossil now has 'rename' again. What has happened? Sincerely, Gour -- What is night for all beings is the time of awakening for the self-controlled; and the time of awakening for all beings is night for the introspective sage. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] how to maintain a set of patches?
On Fri, Feb 24, 2012 at 15:12, Gour g...@atmarama.net wrote: On Fri, 24 Feb 2012 08:55:09 -0500 Leo Razoumov slonik...@gmail.com wrote: If the code above does not work you can try poor-man's approach with the patch (untested) fossil co E fossil diff --from P1-parent --to P3 | patch  Please, be aware that patch method does not handle addition/removal of the files. Actually I stand corrected. $ fossil diff --new-file --from P1-parent --to P3 | patch -E should add/remove text files automatically. Binary files, on the other hand still pose a problem. P.S. Maintaining patch sets, squashing/folding are everyday tasks in many popular work-flows. It would be great if fossil supports them natively rather that via ugly hacks. I fully agree with it. ;) Btw, may I ask you do you miss something else in Fossil as (possibly) ex-hg user? I used Hg briefly few years ago. Now I abandoned Hg completely and am an active GIT user for my heavy lifting projects. I recently discovered fossil and find it very refreshing and intriguing. One thing that I miss in fossil above everything else is inability to push/pull individual branches or/and individual artifacts. This is really big item on my wish list. Current fossil model has only two choices: public branches that are accessible to all, and private branches that are for-your-eyes-only. But I need few branches that I share with my team members but do not leak outside of the company. Fossil provides no mechanism to support such a work-flow. --Leo-- ___ 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] how to maintain a set of patches?
On Fri, 24 Feb 2012 18:13:15 -0500 Leo Razoumov slonik...@gmail.com wrote: Actually I stand corrected. $ fossil diff --new-file --from P1-parent --to P3 | patch -E should add/remove text files automatically. Binary files, on the other hand still pose a problem. OK. Thanks. I used Hg briefly few years ago. Now I abandoned Hg completely and am an active GIT user for my heavy lifting projects. I recently discovered fossil and find it very refreshing and intriguing. I simply cannot stand Git considering it's too complex as a DVCS tool forcing one to think more about the the tool than I'm ready to do. Maybe I'm just spoiled with Darcs. ;) One thing that I miss in fossil above everything else is inability to push/pull individual branches or/and individual artifacts. This is really big item on my wish list. Current fossil model has only two choices: public branches that are accessible to all, and private branches that are for-your-eyes-only. Afaik, it's possible to push private branches as well, but, I agree, Fossil is mostly 'all or nothing'. I'd like to be able to get rid (or as HG says 'close') of old experimental branches whose patches are applied to the trunk without the need to resort too many different hacks. But I need few branches that I share with my team members but do not leak outside of the company. Fossil provides no mechanism to support such a work-flow. Right. I'd like to have simple 'rollback' as well in a situation when I quickly find out that the commit was simply mistake... Sincerely, Gour -- Therefore, without being attached to the fruits of activities, one should act as a matter of duty, for by working without attachment one attains the Supreme. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] how to maintain a set of patches?
On Fri, 10 Feb 2012 15:46:15 -0500 Leo Razoumov slonik...@gmail.com wrote: I am sorry if my language was not clear. Here are the diagrams: I am sorry to jump in this thread...we might soon start working on our application which is meant for niche market and therefore potential contributors although experts in the field are probably not savvy with DVCS tools, so Fossil is definitely unprecedented wiht its features and simplicity to setup use. Otoh, we're familiar with DVCS tools (starting from darcs, bzr, mtn) and now being hg user would like to not to lose any functionality from e.g. hg. My question is connected with Mercurial's MQ feature... Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Let's assume I've the same situation like above, but consider that my patches are too granular to commit each one to the trunk and would like to eg. combine P1 P3 together and then apply them as: P2' -- P1_P3' to my trunk. Is it possible to do it in Fossil? Mercurial's MQ offers qfold command, and here is the help file for it: [gour@atmarama gour] hg help qfold hg qfold [-e] [-k] [-m TEXT] [-l FILE] PATCH... fold the named patches into the current patch Patches must not yet be applied. Each patch will be successively applied to the current patch in the order given. If all the patches apply successfully, the current patch will be refreshed with the new cumulative patch, and the folded patches will be deleted. With -k/--keep, the folded patch files will not be removed afterwards. The header for each folded patch will be concatenated with the current patch header, separated by a line of * * *. Returns 0 on success. options: -e --edit edit patch header -k --keep keep folded patch files -m --message TEXT use text as commit message -l --logfile FILE read commit message from file use hg -v help qfold to show more info Sincerely, Gour -- There are principles to regulate attachment and aversion pertaining to the senses and their objects. One should not come under the control of such attachment and aversion, because they are stumbling blocks on the path of self-realization. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to maintain a set of patches?
I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. Git has git rebase, Mercurial has hg mq. What solution does fossil offer? --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov slonik...@gmail.com wrote: I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. If you apply a patch once, it is on that branch. To reapply a patch would be a no-op, since the changes are already present on the branch, unless for some reason you had backed the patch out since the prior application. Perhaps I don't understand what you are asking for? Git has git rebase, Mercurial has hg mq. What solution does fossil offer? --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 15:28, Richard Hipp d...@sqlite.org wrote: On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov slonik...@gmail.com wrote: I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. If you apply a patch once, it is on that branch. To reapply a patch would be a no-op, since the changes are already present on the branch, unless for some reason you had backed the patch out since the prior application. Perhaps I don't understand what you are asking for? I am sorry if my language was not clear. Here are the diagrams: I start my-patches branch from trunk commit B and organize my changes as a set of patches each one addressing specific issue. AB-- = trunk \-P1--P2--P3 = my-patches Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Now I want to reapply (I am avoiding word rebase) my patches P1 through P3 to the trunk commit E to achieve something like this /-P1'--P2'--P3' = my-patches ABCDE-- = trunk \-P1--P2--P3 = closed I am effectively rebasing my patches to the new trunk commit and I will close the leaf on the old branch. If I use merge then all three patches will be squashed into a single change-set. I would rather prefer to keep them as individual patches. --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 3:46 PM, Leo Razoumov slonik...@gmail.com wrote: On Fri, Feb 10, 2012 at 15:28, Richard Hipp d...@sqlite.org wrote: On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov slonik...@gmail.com wrote: I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. If you apply a patch once, it is on that branch. To reapply a patch would be a no-op, since the changes are already present on the branch, unless for some reason you had backed the patch out since the prior application. Perhaps I don't understand what you are asking for? I am sorry if my language was not clear. Here are the diagrams: I start my-patches branch from trunk commit B and organize my changes as a set of patches each one addressing specific issue. AB-- = trunk \-P1--P2--P3 = my-patches Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Now I want to reapply (I am avoiding word rebase) my patches P1 through P3 to the trunk commit E to achieve something like this /-P1'--P2'--P3' = my-patches ABCDE-- = trunk \-P1--P2--P3 = closed I am effectively rebasing my patches to the new trunk commit and I will close the leaf on the old branch. If I use merge then all three patches will be squashed into a single change-set. I would rather prefer to keep them as individual patches. fossil update D fossil merge --cherrypick P1 fossil commit --branch P1p fossil merge --cherrypick P2 fossil commit --tag P2p fossil merge --cherrypick P3 fossil commit --tag P3p --Leo-- -- 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 15:54, Richard Hipp d...@sqlite.org wrote: fossil update D fossil merge --cherrypick P1 fossil commit --branch P1p fossil merge --cherrypick P2 fossil commit --tag P2p fossil merge --cherrypick P3 fossil commit --tag P3p Richard, thanks for the suggestion. Will I have to manually provide commit messages for each commit? --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 4:07 PM, Leo Razoumov slonik...@gmail.com wrote: On Fri, Feb 10, 2012 at 15:54, Richard Hipp d...@sqlite.org wrote: fossil update D fossil merge --cherrypick P1 fossil commit --branch P1p fossil merge --cherrypick P2 fossil commit --tag P2p fossil merge --cherrypick P3 fossil commit --tag P3p Richard, thanks for the suggestion. Will I have to manually provide commit messages for each commit? Yes. And you'll need to manually resolve any merge conflicts that come up to. --Leo-- -- 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov slonik...@gmail.com wrote: I hope that fossil could pre-populate the message with the text from the commit that is being cherry-picked. It would save lots of typing. A very reasonable suggestion. The latest trunk version of fossil does this. http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1 -- 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 18:38, Richard Hipp d...@sqlite.org wrote: On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov slonik...@gmail.com wrote: I hope that fossil could pre-populate the message with the text from the commit that is being cherry-picked. It would save lots of typing. A very reasonable suggestion. The latest trunk version of fossil does this. http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1 Wow! That was fast (under 2 hours for a feature)!! Thanks, --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
