Veracity Q&A home login about faq

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 cp commands are merely an easy way to simulate changes. The extraneous ones are to save the state of example.c at each important stage.


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 vvupdates work, while the third one fails?

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 vv update appears to be triggered by the presence of any uncontrolled files, not just those related to the updates and merges (I was thinking the problem might just have been triggered by a hash collision among identical files, but this definitely not the case; it fails when any old file is present).



Original post:

After a few simple (I think) merges, I get this:

> vv diff
(Empty response; I deduce that the working copy is clean)

> vv branch
cm2 (This is a branch I've just successfully committed a merge to)

> vv update -b b
vv.exe: Error 192 (sglib): Conflicts or changes
in the working directory prevented UPDATE: 
There are uncommitted changes in the working directory 
and the goal changeset is not a descendant 
or ancestor of the current baseline.

I won't (just yet) overload things by posting the full traceback, nor the sequence of vvs leading up to this, just in case it's easy to answer. Otherwise, please just ask.


I've added the full log below, to replace this. Sorry it's so long.

After removing the "Found:" files, vv update -b b works fine.

However, my expectations (perhaps wrongly) were these:

  1. These files are uncontrolled (in all branches), and so shouldn't interfere with anything
  2. These files were also present at a previous vv update -b c which appeared to work perfectly

Here's the full log. Please feel free to prune the excess:

> rm -rf .sgdrawer
> vv repo delete BadMerge
Deleting BadMerge... Done.
> vv init BadMerge
> vv whoami --create root@nowhere.org
> vv add example.c
> vv branch new a
Working copy attached to a. A new head will be created with the next commit.
> cp a.c example.c
> vv commit -m"Checkin a"

    revision:  2:1a9dc317e3ab46814609c4a07125ad30d45baab6
      branch:  a
         who:  root@nowhere.org
        when:  2011/07/22 19:48:32.698 +0100
     comment:  Checkin a
      parent:  1:349df8644145d9880daf04184c9faf1fc61f8e9e
> vv tag add a1
> vv branch new b
Working copy attached to b. A new head will be created with the next commit.
> cp b1.c example.c
> vv commit -m"Checkin b1"

    revision:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
      branch:  b
         who:  root@nowhere.org
        when:  2011/07/22 19:48:37.025 +0100
     comment:  Checkin b1
      parent:  2:1a9dc317e3ab46814609c4a07125ad30d45baab6
> vv tag add b1
> cp b2.c example.c
> vv commit -m"Checkin b2" 
    revision:  4:ee780fe2d0c4286de5127d31eec4e10899f1d9c4
      branch:  b
         who:  root@nowhere.org
        when:  2011/07/22 19:48:39.592 +0100
     comment:  Checkin b2
      parent:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
> vv tag add b2
> vv update -b a
> vv branch new c
Working copy attached to c. A new head will be created with the next commit.
> cp c1.c example.c
> vv commit -m"Checkin c1" 
    revision:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      branch:  c
         who:  root@nowhere.org
        when:  2011/07/22 19:48:43.458 +0100
     comment:  Checkin c1
      parent:  2:1a9dc317e3ab46814609c4a07125ad30d45baab6
> vv tag add c1
> vv branch new cm1
Working copy attached to cm1. A new head will be created with the next commit.
> vv merge -b b
1 updated, 0 deleted, 0 added, 1 merged, 0 unresolved
> vv commit -m"Merge branch b"
    revision:  6:0b3409d36e096225dcfda988fd8fc108d9e99fda
      branch:  cm1
         who:  root@nowhere.org
        when:  2011/07/22 19:48:47.511 +0100
     comment:  Merge branch b
      parent:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      parent:  4:ee780fe2d0c4286de5127d31eec4e10899f1d9c4
> cp example.c cm1.c
> vv update -b c
> vv branch new cm2 
Working copy attached to cm2. A new head will be created with the next commit.
> vv merge --tag b1
1 updated, 0 deleted, 0 added, 1 merged, 0 unresolved
> vv commit -m"Merge tag b1"
    revision:  7:26ffacfb651ee71601b99d7c65d78e274839dc18
      branch:  cm2
         who:  root@nowhere.org
        when:  2011/07/22 19:48:51.754 +0100
     comment:  Merge tag b1
      parent:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      parent:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
> cp example.c cm2.1.c
> vv diff
> vv status --verbose
   Found:  @/.temp
   Found:  @/a.c
   Found:  @/b1.c
   Found:  @/b2.c
   Found:  @/bmerge.sh
   Found:  @/c1.c
   Found:  @/cm1.c
   Found:  @/cm2.1.c
   Found:  @/cm2.2.c
   Found:  @/history.txt
   Found:  @/log.txt
   Found:  @/m1.git.c
   Found:  @/m2.darcs.c
   Found:  @/vv.help.txt
> vv parents
Parents of pending changes in working copy:
    revision:  7:26ffacfb651ee71601b99d7c65d78e274839dc18
      branch:  cm2
         who:  root@nowhere.org
        when:  2011/07/22 19:48:51.754 +0100
     comment:  Merge tag b1
      parent:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      parent:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
> vv heads
    revision:  6:0b3409d36e096225dcfda988fd8fc108d9e99fda
      branch:  cm1
         who:  root@nowhere.org
        when:  2011/07/22 19:48:47.511 +0100
     comment:  Merge branch b
      parent:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      parent:  4:ee780fe2d0c4286de5127d31eec4e10899f1d9c4
    revision:  7:26ffacfb651ee71601b99d7c65d78e274839dc18
      branch:  cm2
         who:  root@nowhere.org
        when:  2011/07/22 19:48:51.754 +0100
     comment:  Merge tag b1
      parent:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      parent:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
    revision:  2:1a9dc317e3ab46814609c4a07125ad30d45baab6
      branch:  a
         who:  root@nowhere.org
        when:  2011/07/22 19:48:32.698 +0100
         tag:  a1
     comment:  Checkin a
      parent:  1:349df8644145d9880daf04184c9faf1fc61f8e9e
    revision:  1:349df8644145d9880daf04184c9faf1fc61f8e9e
      branch:  master
         who:  nobody
        when:  2011/07/22 19:48:27.730 +0100
    revision:  5:52d9253ac4f4235f32ca4c1975295f80de233d72
      branch:  c
         who:  root@nowhere.org
        when:  2011/07/22 19:48:43.458 +0100
         tag:  c1
     comment:  Checkin c1
      parent:  2:1a9dc317e3ab46814609c4a07125ad30d45baab6
    revision:  4:ee780fe2d0c4286de5127d31eec4e10899f1d9c4
      branch:  b
         who:  root@nowhere.org
        when:  2011/07/22 19:48:39.592 +0100
         tag:  b2
     comment:  Checkin b2
      parent:  3:8ce7a39590aad4342fddbffce8c056abb80e3fa1
> vv update -b b
vv.exe: Error 192 (sglib): Conflicts or changes in the working copy prevented UPDATE: There are uncommitted changes in the working copy and the goal changeset is not a descendant or ancestor of the current baseline.

    c:\work\s\sprawl\public\src\libraries\ut\sg_pendingtree__private_update_baseline.h:165
    c:\work\s\sprawl\public\src\libraries\ut\sg_pendingtree__private_update_baseline.h:5304
    c:\work\s\sprawl\public\src\libraries\ut\sg_pendingtree__private_update_baseline.h:5407
    c:\work\s\sprawl\public\src\libraries\ut\sg_vv_verbs__update.h:78
    c:\work\s\sprawl\public\src\libraries\ut\sg_vv_verbs__update.h:189
    c:\work\s\sprawl\public\src\cmd\sg__do_cmd_update.c:114
    c:\work\s\sprawl\public\src\cmd\sg.c:8384
    c:\work\s\sprawl\public\src\cmd\sg.c:9383
    c:\work\s\sprawl\public\src\cmd\sg.c:963892

asked Jul 22 '11 at 12:44

BrentL's gravatar image

BrentL
1315513

edited Jul 23 '11 at 05:33

I would like to see what vv status has to say, or vv status --verbose if that's empty.

(Jul 22 '11 at 13:03) Paul Roub ♦♦

Just a comment... vv help brach has boatload of help text!

(Jul 22 '11 at 13:22) acbova
1

@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.

(Jul 22 '11 at 13:59) BrentL

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.

link

answered Jul 25 '11 at 14:44

Jeff%20Hostetler's gravatar image

Jeff Hostetler ♦♦
1.8k928

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.

link

answered Jul 22 '11 at 13:27

Jeff%20Hostetler's gravatar image

Jeff Hostetler ♦♦
1.8k928

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.

$ 
$ echo "a.c" >> a.c
$ echo "b1.c" > b1.c
$ echo "b2.c" > b2.c
$ echo "c1.c" > c1.c
$ 
$ 
$ mkdir BadMerge
$ cd BadMerge
$ vv init BadMerge .
$ vv whoami --create foo@bar
$ 
$ 
$ date > example.c
$ vv add example.c
$ vv branch new a
Working copy attached to a. A new head will be created with the next commit.
$ cp ../a.c example.c 
$ vv commit -m "Checkin a"

        revision:  2:7ac0254a1168227c1473413137b2d62be62d554b
          branch:  a
             who:  foo@bar
            when:  2011/07/22 17:53:38.421 -0400
         comment:  Checkin a
          parent:  1:96cd79fe9e208acc3bb3268a6fda146c146dd494
$ vv tag add a1
$ 
$ 
$ 
$ vv branch new b
Working copy attached to b. A new head will be created with the next commit.
$ cp ../b1.c example.c 
$ vv commit -m "Checkin b1"

        revision:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778
          branch:  b
             who:  foo@bar
            when:  2011/07/22 17:54:06.729 -0400
         comment:  Checkin b1
          parent:  2:7ac0254a1168227c1473413137b2d62be62d554b
$ vv tag add b1
$ 
$ 
$ 
$ cp ../b2.c example.c 
$ vv commit -m "Checkin b2"

        revision:  4:0431cc862ce44251803ffb8f245743e09247c835
          branch:  b
             who:  foo@bar
            when:  2011/07/22 17:54:59.576 -0400
         comment:  Checkin b2
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778
$ vv tag add b2
$ 
$ 
$ 
$ vv update -b a
$ vv branch new c
Working copy attached to c. A new head will be created with the next commit.
$ cp ../c1.c example.c 
$ vv commit -m "Checkin c1"

        revision:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
          branch:  c
             who:  foo@bar
            when:  2011/07/22 17:55:43.709 -0400
         comment:  Checkin c1
          parent:  2:7ac0254a1168227c1473413137b2d62be62d554b
$ vv tag add c1
$ 
$ 
$ 
$ vv branch new cm1
Working copy attached to cm1. A new head will be created with the next commit.
$ vv merge -b b
1 updated, 0 deleted, 0 added, 1 merged, 1 unresolved
$ vv resolve list --all
Unresolved contents conflict on File: @/example.c
  Baseline Path: @/example.c
  Problem: Merge couldn't generate the item's contents.
  Cause(s):
    Edit/Edit: Changes to item's contents in different branches conflict.
  Possible Contents: (use 'diff' to examine, * indicates merge leaf)
    ancestor
    baseline*
    other*
    merge:     automatically merged from 'baseline' and 'other' with ':merge'
    working

$ vv resolve accept baseline example.c
Accepted 'baseline' value for 'contents' conflict on File:
  @/example.c
$ vv status
$
$ 
$ 
$ vv commit -m "Merge branch b into c giving cm1"

        revision:  6:7037675ec01c40bb4a345845bb5cc2d64463b1c8
          branch:  cm1
             who:  foo@bar
            when:  2011/07/22 18:00:51.860 -0400
         comment:  Merge branch b into c giving cm1
          parent:  4:0431cc862ce44251803ffb8f245743e09247c835
          parent:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
$ vv tag add cm1
$ 
$ 
$ 
$ vv update -b c
$ vv branch new cm2
Working copy attached to cm2. A new head will be created with the next commit.
$ 
$ 
$ 
$ vv merge --tag b1
1 updated, 0 deleted, 0 added, 1 merged, 1 unresolved
$ vv resolve accept baseline example.c
Accepted 'baseline' value for 'contents' conflict on File:
  @/example.c
$ vv commit -m "Merge by tag b1 into c giving cm2"

        revision:  7:cec7f43b58adc7db61fc0145a07a3b983e7f4423
          branch:  cm2
             who:  foo@bar
            when:  2011/07/22 18:02:28.786 -0400
         comment:  Merge by tag b1 into c giving cm2
          parent:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778
$ vv tag add cm2
$ 
$ 
$ 
$ vv heads

        revision:  6:7037675ec01c40bb4a345845bb5cc2d64463b1c8
          branch:  cm1
             who:  foo@bar
            when:  2011/07/22 18:00:51.860 -0400
             tag:  cm1
         comment:  Merge branch b into c giving cm1
          parent:  4:0431cc862ce44251803ffb8f245743e09247c835
          parent:  5:734c2b7c43b3f755685523b473f7c2101a0f2552

        revision:  7:cec7f43b58adc7db61fc0145a07a3b983e7f4423
          branch:  cm2
             who:  foo@bar
            when:  2011/07/22 18:02:28.786 -0400
             tag:  cm2
         comment:  Merge by tag b1 into c giving cm2
          parent:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778

        revision:  4:0431cc862ce44251803ffb8f245743e09247c835
          branch:  b
             who:  foo@bar
            when:  2011/07/22 17:54:59.576 -0400
             tag:  b2
         comment:  Checkin b2
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778

        revision:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
          branch:  c
             who:  foo@bar
            when:  2011/07/22 17:55:43.709 -0400
             tag:  c1
         comment:  Checkin c1
          parent:  2:7ac0254a1168227c1473413137b2d62be62d554b

        revision:  2:7ac0254a1168227c1473413137b2d62be62d554b
          branch:  a
             who:  foo@bar
            when:  2011/07/22 17:53:38.421 -0400
             tag:  a1
         comment:  Checkin a
          parent:  1:96cd79fe9e208acc3bb3268a6fda146c146dd494

        revision:  1:96cd79fe9e208acc3bb3268a6fda146c146dd494
          branch:  master
             who:  nobody
            when:  2011/07/22 17:52:10.937 -0400
$ 
$ 
$ 
$ vv parents
Parents of pending changes in working copy:

        revision:  7:cec7f43b58adc7db61fc0145a07a3b983e7f4423
          branch:  cm2
             who:  foo@bar
            when:  2011/07/22 18:02:28.786 -0400
             tag:  cm2
         comment:  Merge by tag b1 into c giving cm2
          parent:  5:734c2b7c43b3f755685523b473f7c2101a0f2552
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778
$ 
$ 
$ 
$ vv update -b b
$ 
$ vv parents
Parents of pending changes in working copy:

        revision:  4:0431cc862ce44251803ffb8f245743e09247c835
          branch:  b
             who:  foo@bar
            when:  2011/07/22 17:54:59.576 -0400
             tag:  b2
         comment:  Checkin b2
          parent:  3:a191daf7a5dbfa123d4dedf2b6987e971942a778
$ 
$ 
$ vv update -b cm1
$ vv update -b cm2
$ vv update -b a
$ vv update -b master
$
link

answered Jul 22 '11 at 17:19

Jeff%20Hostetler's gravatar image

Jeff Hostetler ♦♦
1.8k928

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".

link

answered Jul 22 '11 at 14:45

Jeff%20Hostetler's gravatar image

Jeff Hostetler ♦♦
1.8k928

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.

link

answered Jul 25 '11 at 10:40

Jeff%20Hostetler's gravatar image

Jeff Hostetler ♦♦
1.8k928

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×22
×17
×11

Asked: Jul 22 '11 at 12:44

Seen: 3,549 times

Last updated: Aug 01 '11 at 05:17

powered by OSQA