status code philosophy

[Ben Collins-Sussman <su...@newton.collab.net>]

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.

Re: status code philosophy

[Karl Fogel <kf...@galois.collab.net>]

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> How about a compromise: If nothing's changed in the props, print a space 
> instead of a '-'. This way users will mostly see one letter, not two, as 
> expected. If there's a prop change, it just magically shows up, as it 
> should.

That's what's being proposed (or what was intended to be proposed,
except that due to a misunderstanding it wasn't -- Ben had thought Jim
and I were arguing for something else.  But it's all straight now.)

With a special `verbose' flag, of course, you could see the prop
changes happening too, even on clean updates.

Re: status code philosophy

[Branko Čibej <br...@xbc.nu>]

Karl Fogel wrote:

> Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> 
>> Why not just always show both codes? I don't see one extra (meaningful) 
>> character in the output as being problematic.
> 
> 
> JimB's net connection is down, so I'll give the answer he gave
> privately earlier:
> 
> For most users, properties are probably not very important.  They're
> concerned with the text of the file.  And that's the way CVS works
> too, so they're already accustomed to the single letter output.
> 
> When the local user starts actually doing something with properties,
> then of course status lines will show that.  But clean (non-merging)
> property updates are probably better done silently.
> 
> FWIW, I think Jim's reasoning is solid.

Mayhaps I see a soft spot in it ... :-)

>   A single letter by default is
> less noisy, and (bonus) the way CVS behaves anyway.

A simple "svn rename" can cause a prop conflict.

How about a compromise: If nothing's changed in the props, print a space 
instead of a '-'. This way users will mostly see one letter, not two, as 
expected. If there's a prop change, it just magically shows up, as it 
should.

> Yeah.  Ben, this is all part of the tree delta conflict table that
> we've been working on (see whiteboard :-) ).

I see it. :-)

-- 
Brane �ibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/

Re: status code philosophy

[Karl Fogel <kf...@galois.collab.net>]

Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> Why not just always show both codes? I don't see one extra (meaningful) 
> character in the output as being problematic.

JimB's net connection is down, so I'll give the answer he gave
privately earlier:

For most users, properties are probably not very important.  They're
concerned with the text of the file.  And that's the way CVS works
too, so they're already accustomed to the single letter output.

When the local user starts actually doing something with properties,
then of course status lines will show that.  But clean (non-merging)
property updates are probably better done silently.

FWIW, I think Jim's reasoning is solid.  A single letter by default is
less noisy, and (bonus) the way CVS behaves anyway.

> > QUERY 2:  Will we ever see anything other than a '-' in the first
> > field of a directory's status line?
> 
> Absolutely. Additions and removals, modify the contents of the 
> directory, and conflicts can arise. They should be marked.

Yep!

> > Specifically, a conflict over what the directories contents ("text") should be?
> 
> Two additions of the same file should conflict; likewise removal vs. 
> modification. That could be all, I guess (two different renames are 
> property conflicts on the renamed node, not the containing directory).

Yeah.  Ben, this is all part of the tree delta conflict table that
we've been working on (see whiteboard :-) ).

Re: status code philosophy

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:
[snippety...]

> QUERY 1:  Does this make sense to people?

Why not just always show both codes? I don't see one extra (meaningful) 
character in the output as being problematic.

[...snip]

> QUERY 2:  Will we ever see anything other than a '-' in the first
> field of a directory's status line?

Absolutely. Additions and removals, modify the contents of the 
directory, and conflicts can arise. They should be marked.

> Specifically, a conflict over what the directories contents ("text") should be?

Two additions of the same file should conflict; likewise removal vs. 
modification. That could be all, I guess (two different renames are 
property conflicts on the renamed node, not the containing directory).

-- 
Brane �ibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/