Right now we're tracking each working copy file's text and properties
independently. In other words, we have separate timestamps for text
and props. If there's a conflict during merge, a ".rej" and/or
".prej" file is created and tracked. The file is assumed to be in a
permanent state of conflict until the user deliberately removes the
relevant reject file(s).
(This was Jim's excellent idea: rather than looking at timestamps to
decide if the user had removed the conflict, it's better to make the
user *proactively* remove the reject file. This is a Good Thing;
we're not placing >>>>> markers in the file, so a conflicting file
will still compile, so there's a risk of people forgetting to resolve
the conflict before committing. However, in our current system, the
commit won't succeed if the reject file still exists.)
But I digress.
Because each file has two parts, we have two independent status codes
per file. Over a phone discussion, Karl/Jim/Ben formed an opinion
* Don't show both status codes unless the user explicitly asks for
them (some kind of --verbose (?) switch). Just default to showing a
single, simplified code.
* It's okay to show both codes if local mods are detected on a file's
properties. At that point, innocence is lost -- the user obviously
knows what's up.
QUERY 1: Does this make sense to people?
Btw, here's an example of the status codes in action, as an example:
After applying an XML patch to my t1/ working directory that adds
properties to t1/iota, I see this when I run `svn status tests/t1/iota`:
-- 9 ( none ) tests/t1/iota
Then after editing this file's properties, I see
-M 9 ( none ) tests/t1/iota
Then when I update again and get a conflicting property, I see
-C 11 ( none ) tests/t1/iota
If I edit iota's text, I see
MC 11 ( none ) tests/t1/iota
And then if I delete the ".prej" file sitting next to iota, Subversion
assumes that I've fixed the conflict. But it still notices that the
properties are locally changed.
MM 11 ( none ) tests/t1/iota
QUERY 2: Will we ever see anything other than a '-' in the first
field of a directory's status line?
Directories have genuine properties, so the second status code may
change all the time. But what does it mean to have a directory with
Here's one idea: if I `svn add` a file to a directory, has the
directory's text been locally modified? Perhaps, if you think of a
directory's "text" as a list of dirents. Along this line: if you
locally delete a file with `svn rm` and then discover that an update
wants to patch the file, wouldn't this be a conflict? Specifically, a
conflict over what the directories contents ("text") should be?
I'd like to hear if people think this is sound reasoning.
Received on Sat Oct 21 14:36:15 2006