Re: [Monotone-devel] What are rosters?

[Brian May]

>>>>> "William" == William Uther <address@hidden> writes:

    William> If we just do what I said above, then we'd lose history.  We'd also
    William> need to make sure that the revision we resurrect the node from is a
    William> parent of the new revision generated.  This might be best done by
    William> cloning merge_into_dir quite closely, and so the resurrect command
    William> would actually commit its own revision rather than being a 
workspace
    William> command.  This is probably ok as you can use revert to get back a
    William> file that you've deleted but not committed yet.

Would this still work even if the undeleted file is deleted again?

A   file created
|
B   file edited
|
C   file deleted
|
D   file undeleted
|
E   file edited
|
F   file deleted

If say, I was to fork C to C1 and merge into D to form D1, would the
file exist or not, or would this result in a conflict?

Hmmm. Lets see if we can turn this into a table, what would happen if
you merge one version if the other...


Y = file exists
N = file doesn't exist
C = conflicts
- = parent version; makes no sense


     A  B  C  D  E  F
A1   -  Y     Y  Y
B1   Y  -     Y  Y
C1         -        N
D1   Y  Y     -
E1   Y  Y        -
F1         N        -


I have inserted some of the simpler values that require no thinking on
my part ;-). If the file exists in both revisions, it probably should
stay, and if the file doesn't exist in both versions, it probably
should not exist. Maybe the rest should be conflicts.

Revision F might get interesting, because, at this stage, the file has
been deleted twice. So C1 to F probably should not conflict, although
it is a different delete.
-- 
Brian May <address@hidden>