Re: [fossil-users] Enhancement: commit and close merged leaf
2013/8/2 Andy Bradford amb-sendok-1377995615.lfipjljlncecmjghe...@bradfords.org: Does this mean that the merged fork is no longer a leaf at all? If this is the case, why assign a closed tag to it? I never tried fossil merge --integrate for merging a fork before, but it seems to me that assigning a closed tag to it makes a slight difference. Using --integrate makes it impossible for the person who created the fork to do further commits on the fork. With a normal merge, the node doesn't show on the leaves page, but still can be committed to. That difference is useful! I don't know why the timeline doesn't display Closed Leaf for [53ce8d2863], I would expect it to be there indicating that this fork no longer can be committed to. Looks like a (minor) bug to me. Thanks! 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] Enhancement: commit and close merged leaf
2013/8/2 Jan Nijtmans jan.nijtm...@gmail.com: 2013/8/2 Andy Bradford amb-sendok-1377995615.lfipjljlncecmjghe...@bradfords.org: Does this mean that the merged fork is no longer a leaf at all? If this is the case, why assign a closed tag to it? ... Using --integrate makes it impossible for the person who created the fork to do further commits on the fork. At further thought, trying to do further commits in the fork gives: would fork. update first or use --allow-fork. so it is already impossible to do further commits there. So, I think you are right, Andy, adding the +closed tag doesn't really make a difference here. I wonder why the function is_a_leaf() doesn't return 0 here: http://www.fossil-scm.org/index.html/artifact/14988f3864?ln=1698 If the merged is not a leaf anymore, due to the commit itself, I would expect this function to protect from adding a closed tag (even though it doesn't really harm here). Hm. Thanks! 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] Enhancement: commit and close merged leaf
2013/8/2 Jan Nijtmans jan.nijtm...@gmail.com: If the merged is not a leaf anymore, due to the commit itself, I would expect this function to protect from adding a closed tag (even though it doesn't really harm here). Hm. Bug fixed here: http://www.fossil-scm.org/index.html/info/9eb3f5f605 Thanks very much, Stephan and Andy, for testing the (illegal) usage of --integrate on a fork merge. What is supposed to happen is: $ fossil merge --integrate cannot use --backout, --cherrypick or --integrate with a fork merge Correct! $ fossil merge --integrate trunk .. fossil undo is available to undo changes to the working checkout. Here the fossil merge is fooled in thinking this is NOT a fork merge, by implicitly using trunk as argument. $ fossil commit Not_Closed: 4a89da5de27bee058f4cc6a358fb9bd6726b4c0b (not a leaf any more) That is what I expect! The commit itself already removes the Leaf status from the node, so adding the closed tag doesn't make sense any more. The is_a_leaf() function gave the wrong answer because the manifest_crosslink() function was not called yet, which is supposed to adapt the tables to the new situation. Thanks for noticing this! 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] Enhancement: commit and close merged leaf
Thus said Jan Nijtmans on Thu, 01 Aug 2013 10:03:36 +0200: Thanks for your testing and your feedback! It's on trunk now. I used merge --integrate when doing that. One other thing I noticed is that when merging in a forked trunk with --integrate, it will explicitly close the trunk, which I suppose isn't necessarily bad, but that pretty much implicitly happens when merging in a fork already. Or in other words, a merged fork no longer shows up as a leaf, but neither does it show up as a Closed Leaf, despite the fact that it now has a closed tag. This can be seen here: http://www.fossil-scm.org/index.html/timeline?f=366f1ae6da39e110 Notice that the fork [53ce8d2863] when merged into [366f1ae6da] no longer shows up as a leaf. Does this mean that the merged fork is no longer a leaf at all? If this is the case, why assign a closed tag to it? Andy -- TAI64 timestamp: 400051fafe82 ___ 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] Enhancement: commit and close merged leaf
Thus said Jan Nijtmans on Tue, 30 Jul 2013 10:11:52 +0100: http://www.fossil-scm.org/index.html/info/2015bbd55d Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! It might be a little late in the game, but why is it called integrate? Maybe I missed the discussion about why it is called that---I'll scour the archives. Something like --closeleaf would seem to be more representative of what it does. I tested it out and it worked. I even was able to close trunk with it by doing: fossil update branch fossil merge --integrate trunk Getting a new trunk was also kind of interesting. I'm not suggesting that this be prevented, by the way, because it's already possible to close the ``trunk'' leaf. Andy -- TAI64 timestamp: 400051f9ca02 ___ 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] Enhancement: commit and close merged leaf
Thus said Andy Bradford on 31 Jul 2013 20:37:19 -0600: It might be a little late in the game, but why is it called integrate? Maybe I missed the discussion about why it is called that---I'll scour the archives. After reading the archives it does appear that --integrate, while not quite as descriptive of the closing aspect, is quite representative of the whole operation that is going on. By the way, I like the option. Making it possible to close the leaf with the merge/commit is quite nice. I even tried to trick it by doing: fossil merge --integrate non-leaf-branch-artifact-id And it ignored the fact that it wasn't a leaf and just did a normal merge. Nice! Thanks, Andy -- TAI64 timestamp: 400051f9f264 ___ 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] Enhancement: commit and close merged leaf
2013/7/12 Stephan Beal sgb...@googlemail.com: On Fri, Jul 12, 2013 at 10:25 AM, Jan Nijtmans wrote: Well, just try out the merge-integrate branch. I would say the glass is full again.;-) Indeed it is! i like what you've done :) I made one additional change: adding states UPDATED_BY_INTEGR and ADDED_BY_INTEGR (comparable to their XXX_BY_MERGE equivalent) in fossil (status|changes|ls -v) See: http://www.fossil-scm.org/index.html/info/2015bbd55d Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! Thanks, 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 10:11:52AM +0100, Jan Nijtmans wrote: 2013/7/12 Stephan Beal sgb...@googlemail.com: On Fri, Jul 12, 2013 at 10:25 AM, Jan Nijtmans wrote: Well, just try out the merge-integrate branch. I would say the glass is full again.;-) Indeed it is! i like what you've done :) I made one additional change: adding states UPDATED_BY_INTEGR and ADDED_BY_INTEGR (comparable to their XXX_BY_MERGE equivalent) in fossil (status|changes|ls -v) See: http://www.fossil-scm.org/index.html/info/2015bbd55d Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! Hello all, I'll try to add some feedback. :) Why INTEGR, and not INTEGRATE? There is also case -1, -2, -4. Why not -3? About the code starting at line 1693, it looks to me like it runs in any case. Does this change only add a new --integrate, or it also changes the behaviour of usual merges? Regards, Lluís. ___ 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 11:11 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: I made one additional change: adding states UPDATED_BY_INTEGR and ADDED_BY_INTEGR For a moment i thought you were trying to save 1 byte from INTEGER and i was going to heckle you about it ;). But i see now that it's INTEGRATE. How about ..._BY_INTEGR8? Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! i like it. -- - 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: Why INTEGR, and not INTEGRATE? 2013/7/30 Stephan Beal sgb...@googlemail.com: For a moment i thought you were trying to save 1 byte from INTEGER and i was going to heckle you about it ;). But i see now that it's INTEGRATE. How about ..._BY_INTEGR8? LOL Well, the colums are not aligned anyway, so I guess INTEGRATE would be just as well. (An earlier version used ADD_BY_INTEGR/CHG_BY_INTEGR, in an attempt to keep the colums in the output well-aligned) There is also case -1, -2, -4. Why not -3? There's no need to keep values continuous, just keeping some room for future improvements. -3 is just as good. Thanks! 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: About the code starting at line 1693, it looks to me like it runs in any case. Does this change only add a new --integrate, or it also changes the behaviour of usual merges? That code does an additional pass over the vmerge table, in order to determine which branches should be closed. Existing merges never produce id=-4 so the query will give the empty result then. 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 10:45:31AM +0100, Jan Nijtmans wrote: 2013/7/30 Lluís Batlle i Rossell vi...@viric.name: About the code starting at line 1693, it looks to me like it runs in any case. Does this change only add a new --integrate, or it also changes the behaviour of usual merges? That code does an additional pass over the vmerge table, in order to determine which branches should be closed. Existing merges never produce id=-4 so the query will give the empty result then. But maybe it should not run unless in 'integrate' mode? ___ 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: But maybe it should not run unless in 'integrate' mode? That's not possible. This code is part of fossil commit while the --integrate option is from fossil merge. The fossil commit needs to know whether a previous fossil merge had the --integrate option, the vmerge table is where this information can be found. 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] Enhancement: commit and close merged leaf
2013/7/11 Harald Oehlmann harald.oehlm...@elmicron.de: Looks really helpful and well thought (but I am even more in Stephans position to stay quiet due to big lack of understanding...) Implementation is complete now and well-tested in the merge-integrate branch. Feedback welcome! Closing a branch could also be done in the command line with: fossil tag add --raw closed branch but this lacks the necessary checks whether branch is a leaf or maybe already closed. fossil merge --integrate has those checks now. 2013/7/10 Harald Oehlmann harald.oehlm...@elmicron.de: Am 10.07.2013 11:51, schrieb Stephan Beal: On Wed, Jul 10, 2013 at 9:37 AM, Harald Oehlmann harald.oehlm...@elmicron.de mailto:harald.oehlm...@elmicron.de wrote: 1) fossil open repo 2) fossil merge branch 3) fossil commit 4) And then, I go to the web interface and set the closed leaf property of the branch. The last step would be natural for me to de done with the fossil commit. ... It is ok to also initiate it with the fossil merge and do it with fossil commit. The fact to specify it with fossil merge has two advantages: - the closed branch tag is directly in the command, which is clearer - multiple merges may be closed or not by one commit. The current implementation does that exactly. The above steps become: 1) fossil open repo 2) fossil merge --integrate branch 3) fossil commit The merged branch is only closed when the merge is actually committed. So if the used does a fossil undo or fossil revert the branch is kept as if the fossil merge --integrate never happened. And you can do multiple integrations this way before doing a commit: All integrated branches will be closed at commit time. 2013/7/10 Stephan Beal sgb...@googlemail.com: i think i just went from glass half full to glass half empty on this topic :/. Well, just try out the merge-integrate branch. I would say the glass is full again.;-) 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] Enhancement: commit and close merged leaf
Am 12.07.2013 10:25, schrieb Jan Nijtmans: Well, just try out the merge-integrate branch. I would say the glass is full again.;-) Congratulation, very impressive ! - Harald ___ 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] Enhancement: commit and close merged leaf
2013/7/10 Stephan Beal sgb...@googlemail.com: That well surpasses my understanding of how merging is tracked, so i'll just be quiet now ;). Well, merge-tracking is a part of fossil which I understand very well. So I did just a little bit hacking: https://www.fossil-scm.org/index.html/info/b984ecaf1d It actually looks much like the merge --reintegrate command in subversion, although I hate the name reintegrate (and in svn, branches cannot be closed just deleted). This option became deprecated in subversion 1.8 anyway, see http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate I would just choose --integrate for it. Demo: - prepare a branch foo which needs to be integrated to trunk Then from trunk: $ fossil merge --integrate foo UPDATE work/test.txt fossil undo is available to undo changes to the working checkout. $ fossil status UPDATED_BY_MERGE work/test.txt INTEGRATE 8be756e01aecba050b67c3ed3f17bd1c196d7d97 $ fossil commit New_Version: 376eed4109c9b179731b54e34032650c24701360 Cannot close 8be756e01aecba050b67c3ed3f17bd1c196d7d97 because it is not implemented yet The only thing missing is the actual closing of the branch, but everything else should be there ;-) A nice thing is that if you decide not to commit the change, the integrated branch is never closed. You can do a fossil undo or fossil revert and everything is gone. 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] Enhancement: commit and close merged leaf
Am 11.07.2013 11:07, schrieb Jan Nijtmans: 2013/7/10 Stephan Beal sgb...@googlemail.com: That well surpasses my understanding of how merging is tracked, so i'll just be quiet now ;). Well, merge-tracking is a part of fossil which I understand very well. So I did just a little bit hacking: Jan, you are surprising me again and again ! Looks really helpful and well thought (but I am even more in Stephans position to stay quiet due to big lack of understanding...) Admiration, Harald ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Enhancement: commit and close merged leaf
Following hint by Andreas: https://groups.google.com/forum/#!topic/comp.lang.tcl/JwSNrTYgjTk the following enhancement to fossil is proposed: with fossil commit, there should be a possibility (parameter) to close a merged branch. So here is a current typical session to merge a branch to trunk: 1) fossil open repo 2) fossil merge branch 3) fossil commit 4) And then, I go to the web interface and set the closed leaf property of the branch. The last step would be natural for me to de done with the fossil commit. Thank you, Harald ___ 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] Enhancement: commit and close merged leaf
On Wed, Jul 10, 2013 at 9:37 AM, Harald Oehlmann harald.oehlm...@elmicron.de wrote: 1) fossil open repo 2) fossil merge branch 3) fossil commit 4) And then, I go to the web interface and set the closed leaf property of the branch. The last step would be natural for me to de done with the fossil commit. Might it not make more sense for fossil to close the leaf when merging? If it waits until commit then it has to remember and arbitrary number of leaves for arbitrarily long (timespan between merge and commit) and then close them all as part of the commit. The number of potential error cases during the commit then explodes. Closing at merging is also not ideal because it often happens that a merge gets tossed out in the process of trying to fix conflicts (very often i have non-trivial merge conflicts i end up tossing out the merge and starting over from a different angle). :-? -- - 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] Enhancement: commit and close merged leaf
Am 10.07.2013 11:51, schrieb Stephan Beal: On Wed, Jul 10, 2013 at 9:37 AM, Harald Oehlmann harald.oehlm...@elmicron.de mailto:harald.oehlm...@elmicron.de wrote: 1) fossil open repo 2) fossil merge branch 3) fossil commit 4) And then, I go to the web interface and set the closed leaf property of the branch. The last step would be natural for me to de done with the fossil commit. Might it not make more sense for fossil to close the leaf when merging? If it waits until commit then it has to remember and arbitrary number of leaves for arbitrarily long (timespan between merge and commit) and then close them all as part of the commit. The number of potential error cases during the commit then explodes. Closing at merging is also not ideal because it often happens that a merge gets tossed out in the process of trying to fix conflicts (very often i have non-trivial merge conflicts i end up tossing out the merge and starting over from a different angle). Very good idea ! It is ok to also initiate it with the fossil merge and do it with fossil commit. The fact to specify it with fossil merge has two advantages: - the closed branch tag is directly in the command, which is clearer - multiple merges may be closed or not by one commit. I personally would be glad, if I could already manage a single merge... -Harald ___ 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] Enhancement: commit and close merged leaf
On Wed, Jul 10, 2013 at 11:57 AM, Harald Oehlmann harald.oehlm...@elmicron.de wrote: Am 10.07.2013 11:51, schrieb Stephan Beal: ... Closing at merging is also not ideal because it often happens that a merge gets tossed out in the process of trying to fix conflicts (very often i have non-trivial merge conflicts i end up tossing out the merge and starting over from a different angle). Very good idea ! i might have over-thought that problem: closing on merge probably isn't a problem here because if the leaf is closed that doesn't hinder us at all. Closing a leaf keeps us from committing to it, but not from pulling from it. To me closing at merge time sounds like the overall easier approach (but i'm very possibly ignoring/missing details/complications which i'm hoping another list member will point out). Gruss aus Muenchen, -- - 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] Enhancement: commit and close merged leaf
2013/7/10 Stephan Beal sgb...@googlemail.com: i might have over-thought that problem: closing on merge probably isn't a problem here because if the leaf is closed that doesn't hinder us at all. Closing a leaf keeps us from committing to it, but not from pulling from it. To me closing at merge time sounds like the overall easier approach (but i'm very possibly ignoring/missing details/complications which i'm hoping another list member will point out). The only thing to consider is that the merge command doesn't do a sync, so the merged branch might be closed, but no-one else knows that until a commit(with sync) is done. What if - in the mean time - someone else does a commit in the to-be-closed branch? Later, when we do the commit, we are trying to close a node which has successors. Should the commit fail then? And adding a sync after performing a merge-with-close doesn't seem a good idea either: a merge is a local operation now, which cannot fail (assuming the merged branch does exist) A way out could be the following. In the vmerge table, the id field is used for indicating what type of merge it is: 0: MERGED_WITH -1: CHERRYPICK -2: BACKOUT A new value -3 could be added here meaning MERGE_WITH_CLOSE. Then, when committing, a check could be done whether the merged branch is still a leaf. If so, the branch is closed. If not, a warning is printed that the branch couldn't be closed, but it will not influence the success/failure of the commit. How does that sound? 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] Enhancement: commit and close merged leaf
On Wed, Jul 10, 2013 at 4:56 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/7/10 Stephan Beal sgb...@googlemail.com: To me closing at merge time sounds like the overall easier approach (but i'm very possibly ignoring/missing details/complications which i'm hoping another list member will point out) Sometimes i'm so predictable... that until a commit(with sync) is done. What if - in the mean time - someone else does a commit in the to-be-closed branch? Later, when we do the commit, we are trying to close a node which has successors. Should the commit fail then? To quote Bill Murray in his role of Dr. Venkman: Cats and dogs living together! Mass hysteria! And adding a sync after performing a merge-with-close doesn't seem a good idea either: a merge is a local operation now, which cannot fail (assuming the merged branch does exist) i think i just went from glass half full to glass half empty on this topic :/. A way out could be the following. In the vmerge table, the id field is used for indicating what type of merge it is: 0: MERGED_WITHis printed that the branch couldn't be closed, but it will not influence the success/failure of the commit. How does that sound? That well surpasses my understanding of how merging is tracked, so i'll just be quiet now ;). -- - 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
