|
Update: - The original post is now below the double set of dotted lines. Background: - This question arises from my trying to understand the operation of Veracity on a merge controversy which arose between Git and Darcs. The example files I am using can be found here. The Latest state: - When I move all the "Found:" files outside the working copy, the error does not occur. I won't add another enormous log to show this. This leads me to a supplementary question: Given that none of the auxiliary files is under version control in any of the branches, what might be the reason that the first two While you're thinking about that, I'm going to try tweaking a few more variables, such as seeing whether a specific file is triggering this. Thank you all for your patience. Update 6 after additional tests The failure of the third Original post: After a few simple (I think) merges, I get this: I won't (just yet) overload things by posting the full traceback, nor the sequence of I've added the full log below, to replace this. Sorry it's so long. After removing the "Found:" files, However, my expectations (perhaps wrongly) were these:
Here's the full log. Please feel free to prune the excess: |
|
After a little more digging into your example, I can say that the 3rd update was throwing an error because it was an "unrelated" update and there was dirt in the working directory. In this case it was only items with FOUND status. The earlier updates were allowed to succeed because they were "related" (ancestor/descendant) and we allow dirt in the directory to be carried-forward/backward. The dirty check code was considering FOUND items in the same class as changes to controlled items. This was the conservative thing to do, but now seems a little too strong. I just committed a fix to relax that. As for the original reason for your experiment, our builtin merge tool ":merge" will behave more like diff3 than darcs. However, the actual file auto-merge engine that we use can be configured. I can explain that in a separate question if you're interested in that. Jeff, that's very positive; thank you. I'll shortly be asking the auto-merge strategy question for you to expound further...
(Aug 01 '11 at 05:17)
BrentL
|
|
Could you do the following and post back. vv status vv parents vv heads And yes, an empty 'vv diff' should indicate that the working copy is clean. A 'vv status' should tell us the same thing. It's odd that you're getting that message though. I want to see what 'vv parents' says to see if you have an outstanding merge that hasn't been committed; it is possible for a merge result to match or appear identical to the baseline. The other possibility is that you have some un-controlled or ignored files in the current working copy that collide with controlled files in the target branch. Done. I've also added the full log from initing the repo, to give a bit of context. I'm not sure it's a minimum failing example, but it's close...
(Jul 22 '11 at 14:00)
BrentL
|
|
I'm not sure what exactly you did to get the error message. I have recreated the sequence of commands below (omitting some of the stray cp's) in an attempt to duplicate what you did. Since I didn't know the contents of your various *.c files that you seed example.c with, I just made up something. This caused my merges to complain a little because of file content conflicts, so I added a quick resolve to take the baseline version. Can you run through your sequence again as I have here and see if you can isolate what you did differently the first time? Thanks. Jeff, I've done that and updated the question. Thanks.
(Jul 23 '11 at 06:20)
BrentL
|
|
In each of the steps where you create a new file, you need to 'vv add' it before the commit. A good way to see this is to create the file and then do a 'vv status'. The new file should have status "Added" rather than "Found". Sorry, Jeff, I should have made it clearer. In this case, the only file I'm interested in having under version control is example.c. The other files are just bits of telemetry and scaffolding.
(Jul 22 '11 at 14:52)
BrentL
|
|
Thanks for the additional info. I'll re-run my tests with your data files and see if anything different pops out. WRT you last post, yes the Found/uncontrolled files should not affect the result -- provided that they don't collide with things that are under version control in the target changeset of the update. |
I would like to see what
vv statushas to say, orvv status --verboseif that's empty.Just a comment... vv help brach has boatload of help text!
@acbova: Sure does. This is not a criticism, but "I've seen all these words before but never in this order". I'm sure it's all great for those who understand it, but I'm a Veracity (and ancestors) n00b, so, for example, I have no idea what "attach" means in this context, and much less what it implies.