[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    =?UTF-8?B?W0lzc3VlIDk4N10gIFByb2JsZW1zIHdpdGggZmlsZSBhbmQgZGlyZQ==?=
From:       sussman () tigris ! org
Date:       2003-09-26 20:54:19
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=987



User sussman changed the following:

                  What    |Old value                 |New value
================================================================================
                    Status|NEW                       |RESOLVED
--------------------------------------------------------------------------------
                Resolution|                          |FIXED
--------------------------------------------------------------------------------




------- Additional comments from sussman@tigris.org Fri Sep 26 13:54:19 -0700 2003 -------
Okay, so the only reason this issue is still open is because Philip left us with
a lingering question:  "should 'svn st -u' show asterisks next to out-of-date
directories?"

The argument for this:  well, if anyone tries to delete or propchange an
out-of-date directory, commit will fail.  Those are our two rules of directory
versioning.  Shouldn't 'svn st -u' behave the same way with directories as it
does with files?  An asterisk indicates out-of-dateness.

The argument against this:  Karl and I chatted about this, and we both feel that
this move would "cheapen" the asterisk.  At the moment, an asterisk is a
relatively special event -- it triggers a warning bell when you see it.  But
mixed-revision working copies are extremely common.  For example, every time you
commit a single file, you end up with a mixed-rev wc.  You immediately run 'svn
st -u' and see a zillion asterisks (one on every directory in your tree). 
Suddenly they don't really mean anything anymore.  You learn to ignore them.

In general, Karl and I feel that there's no great problem here;   people aren't
being horribly burned by the fact that 'svn st -u' only notices out-of-date files.

What I'm going to do, I think, is close this issue, and open a new post-1.0
issue which covers a broader problem:   we really ought to be more permissive
with out-of-date directory commits.


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@subversion.tigris.org
For additional commands, e-mail: issues-help@subversion.tigris.org

[prev in list] [next in list] [prev in thread] [next in thread]