[Monotone-devel] I think this behavior might be wrong....
I was doing some work, and decided that I wanted to commit that work to a new branch, so as to not distrub other developers too badly... I still haven't completely tested the changes, but it turns out that the changes were included in the main branch anyhow because I then made some other changes to files and commited them against the main branch, without first updating to that branch. At the time I wondered if monotone would be really smart about the thing that I did, but as it turns out, the branch tag I applied to the revision basically made no difference... This is a script which reproduces effectively what I did. What I would have expected in the final checkout would have been 'file' with content 'Branch1' and 'file2' with content 'branch1'. Instead, I get 'file' with content 'branch1 + branch2' but I did not propagate the branches... so I would not have expected the changes to be merged... Maybe an artificial warning/error can be generated to alert the user that such a thing will not produce what they might expect? mtn --db=test.db db init mtn --db=test.db genkey temp mtn --db=test.db --key=temp --branch=branch1 setup . echo Branch1 file mtn --db=test.db --key=temp add file mtn --db=test.db --key=temp commit -m Begin branch1 echo +Branch2 file mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin branch2 echo branch1 file2 mtn --db=test.db --key=temp add file2 mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to branch1 mkdir checkout cd checkout mtn --db=../test.db --key=temp --branch=branch1 co . --- Again, I was working on 'branch', made changes I didn't want to share with the public yet and commited changes on --branch='branch.test'. I then modified other code, and commited that code using --branch='branch' to commit it against the main branch instead of branch.test. But at the end, the changes added to branch.test were included in 'branch' automatically... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I think this behavior might be wrong....
What you're missing in the whole thing is the ancestry. You see, with your last commit (which is to branch1), you're using the previous commit (which is in branch2) as ancestor, so even if you're not doing a propagate, you are producing a history that goes back and forth between the branches. To do what you ask for, you need to do an update in the middle, so it looks like this: mtn --db=test.db db init mtn --db=test.db genkey temp mtn --db=test.db --key=temp --branch=branch1 setup . echo Branch1 file mtn --db=test.db --key=temp add file mtn --db=test.db --key=temp commit -m Begin branch1 echo +Branch2 file mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin branch2 # THIS IS THE MISSING PIECE mtn --db=test.db --key=temp --revision=h:branch1 update echo branch1 file2 mtn --db=test.db --key=temp add file2 mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to branch1 mkdir checkout cd checkout mtn --db=../test.db --key=temp --branch=branch1 co . In message [EMAIL PROTECTED] on Tue, 22 May 2007 01:24:51 -0700, J Decker [EMAIL PROTECTED] said: d3ck0r I was doing some work, and decided that I wanted to commit that work to a d3ck0r new branch, so as to not distrub other developers too badly... I still d3ck0r haven't completely tested the changes, but it turns out that the changes d3ck0r were included in the main branch anyhow because I then made some other d3ck0r changes to files and commited them against the main branch, without first d3ck0r updating to that branch. At the time I wondered if monotone would be really d3ck0r smart about the thing that I did, but as it turns out, the branch tag I d3ck0r applied to the revision basically made no difference... d3ck0r d3ck0r This is a script which reproduces effectively what I did. What I would have d3ck0r expected in the final checkout would have been 'file' with content 'Branch1' d3ck0r and 'file2' with content 'branch1'. Instead, I get 'file' with content d3ck0r 'branch1 + branch2' but I did not propagate the branches... so I would not d3ck0r have expected the changes to be merged... d3ck0r d3ck0r Maybe an artificial warning/error can be generated to alert the user that d3ck0r such a thing will not produce what they might expect? d3ck0r d3ck0r d3ck0r d3ck0r mtn --db=test.db db init d3ck0r mtn --db=test.db genkey temp d3ck0r d3ck0r mtn --db=test.db --key=temp --branch=branch1 setup . d3ck0r d3ck0r echo Branch1 file d3ck0r mtn --db=test.db --key=temp add file d3ck0r mtn --db=test.db --key=temp commit -m Begin branch1 d3ck0r d3ck0r echo +Branch2 file d3ck0r mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin d3ck0r branch2 d3ck0r d3ck0r echo branch1 file2 d3ck0r mtn --db=test.db --key=temp add file2 d3ck0r mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to d3ck0r branch1 d3ck0r d3ck0r mkdir checkout d3ck0r cd checkout d3ck0r mtn --db=../test.db --key=temp --branch=branch1 co . d3ck0r d3ck0r d3ck0r d3ck0r --- d3ck0r d3ck0r d3ck0r d3ck0r Again, I was working on 'branch', made changes I didn't want to share with d3ck0r the public yet and commited changes on --branch='branch.test'. I then d3ck0r modified other code, and commited that code using --branch='branch' to d3ck0r commit it against the main branch instead of branch.test. But at the end, d3ck0r the changes added to branch.test were included in 'branch' automatically... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I think this behavior might be wrong....
On 5/22/07, Richard Levitte [EMAIL PROTECTED] wrote: What you're missing in the whole thing is the ancestry. You see, with your last commit (which is to branch1), you're using the previous commit (which is in branch2) as ancestor, so even if you're not doing a propagate, you are producing a history that goes back and forth between the branches. Yes I understand that if i had updated it would have fixed the issue. and at the time I did the commit I thought about doing an update ... except I knew that the other branch already had split heads, and didn't really want some of the other changes merged inot my current code at that moment isn't there a way to say like 'commit this agains the head of the branch?' oh - except as I just said there' were aready 2 heads so ... To do what you ask for, you need to do an update in the middle, so it looks like this: mtn --db=test.db db init mtn --db=test.db genkey temp mtn --db=test.db --key=temp --branch=branch1 setup . echo Branch1 file mtn --db=test.db --key=temp add file mtn --db=test.db --key=temp commit -m Begin branch1 echo +Branch2 file mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin branch2 # THIS IS THE MISSING PIECE mtn --db=test.db --key=temp --revision=h:branch1 update echo branch1 file2 mtn --db=test.db --key=temp add file2 mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to branch1 mkdir checkout cd checkout mtn --db=../test.db --key=temp --branch=branch1 co . In message [EMAIL PROTECTED] on Tue, 22 May 2007 01:24:51 -0700, J Decker [EMAIL PROTECTED] said: d3ck0r I was doing some work, and decided that I wanted to commit that work to a d3ck0r new branch, so as to not distrub other developers too badly... I still d3ck0r haven't completely tested the changes, but it turns out that the changes d3ck0r were included in the main branch anyhow because I then made some other d3ck0r changes to files and commited them against the main branch, without first d3ck0r updating to that branch. At the time I wondered if monotone would be really d3ck0r smart about the thing that I did, but as it turns out, the branch tag I d3ck0r applied to the revision basically made no difference... d3ck0r d3ck0r This is a script which reproduces effectively what I did. What I would have d3ck0r expected in the final checkout would have been 'file' with content 'Branch1' d3ck0r and 'file2' with content 'branch1'. Instead, I get 'file' with content d3ck0r 'branch1 + branch2' but I did not propagate the branches... so I would not d3ck0r have expected the changes to be merged... d3ck0r d3ck0r Maybe an artificial warning/error can be generated to alert the user that d3ck0r such a thing will not produce what they might expect? d3ck0r d3ck0r d3ck0r d3ck0r mtn --db=test.db db init d3ck0r mtn --db=test.db genkey temp d3ck0r d3ck0r mtn --db=test.db --key=temp --branch=branch1 setup . d3ck0r d3ck0r echo Branch1 file d3ck0r mtn --db=test.db --key=temp add file d3ck0r mtn --db=test.db --key=temp commit -m Begin branch1 d3ck0r d3ck0r echo +Branch2 file d3ck0r mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin d3ck0r branch2 d3ck0r d3ck0r echo branch1 file2 d3ck0r mtn --db=test.db --key=temp add file2 d3ck0r mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to d3ck0r branch1 d3ck0r d3ck0r mkdir checkout d3ck0r cd checkout d3ck0r mtn --db=../test.db --key=temp --branch=branch1 co . d3ck0r d3ck0r d3ck0r d3ck0r --- d3ck0r d3ck0r d3ck0r d3ck0r Again, I was working on 'branch', made changes I didn't want to share with d3ck0r the public yet and commited changes on --branch='branch.test'. I then d3ck0r modified other code, and commited that code using --branch='branch' to d3ck0r commit it against the main branch instead of branch.test. But at the end, d3ck0r the changes added to branch.test were included in 'branch' automatically... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I think this behavior might be wrong....
J == J Decker J writes: J mtn --db=test.db db init J mtn --db=test.db genkey temp J mtn --db=test.db --key=temp --branch=branch1 setup . J echo Branch1 file J mtn --db=test.db --key=temp add file J mtn --db=test.db --key=temp commit -m Begin branch1 J echo +Branch2 file J mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin branch2 Here the working directory contains the branch2 files. J echo branch1 file2 J mtn --db=test.db --key=temp add file2 J mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to branch1 The way I see it, this commit means everything in the working directory will appear as a new revision in branch1. Since the working directory is still branch2, this means everything in branch2 will be included in this new revision. Maybe I am daft and/or misunderstood something, but I fail to see why this is confusing. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] I think this behavior might be wrong....
On 5/22/07, Brian May [EMAIL PROTECTED] wrote: J == J Decker J writes: J mtn --db=test.db db init J mtn --db=test.db genkey temp J mtn --db=test.db --key=temp --branch=branch1 setup . J echo Branch1 file J mtn --db=test.db --key=temp add file J mtn --db=test.db --key=temp commit -m Begin branch1 J echo +Branch2 file J mtn --db=test.db --key=temp --branch=branch2 commit -m Changed file, begin branch2 Here the working directory contains the branch2 files. J echo branch1 file2 J mtn --db=test.db --key=temp add file2 J mtn --db=test.db --key=temp --branch=branch1 commit -m Add a file to branch1 oh dang, i meant to specify file2 specifically on this commit. turns out that that does not modify the end result, since, as someone metioned in an earlier response, this last commit is related with an ancestor of the last commit to branch2, not to the head of branch1. The way I see it, this commit means everything in the working directory will appear as a new revision in branch1. Since the working directory is still branch2, this means everything in branch2 will be included in this new revision. The way I see it, if I specify '--branch=...' as part of a commit line, I would like the diff between the head of that branch and the files specified stored. I would like this diff to be related with an ancestor of the head of the branch specified. If the branch has mutliple heads, require a merge of those heads before allowing the commit to proceed. If there is no branch previously existing, then yes, the branch should be created and related with the current revision marked in the current workspace, however, if the branch does exist, I would expect, again, the diff of the files sepcified (all fiels in the workspace of course if none otheriwse specified) to be commited against the head of the branch specified. Including, if the current branch that the workspace is currently on, is the one that is sp[ecified, but the current revision of the workspace is not the head revision, then the changes should be commited against the head revision, not the current one. If you want the changes to be commited against the current revision in the workspace, just commit. If I had manually updated the revision file without doing any update, monotone would have gladly done the above behavior. Maybe I am daft and/or misunderstood something, but I fail to see why this is confusing. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
