status code philosophy

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
about this:

* 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
modified "text"?

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