You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad ju...@btopenworld.com on 2003/01/27 02:38:09 UTC
svn status handling uncontrolled and non-existant files
Unexpected behaviours of svn status:
- Verbose mode and recursive mode both list uncontrolled files, but do
not list uncontrolled directories.
- When explicitly given the name of an uncontrolled file, it lists its
status as ?, as expected.
- When explicitly given the name of an uncontrolled directory, it fails
and exits without continuing the report:
julianfoad@linux:~/src/subversion svn status *
A A_NEW_DIR
BUGS
CHANGES
COMMITTERS
COPYING
HACKING
IDEAS
INSTALL
? Makefile
Makefile.in
PORTING
README
subversion/libsvn_wc/status.c:718: (apr_err=155007)
svn: Path is not a working copy directory
svn: svn_wc_statuses: apr is not a working copy directory
- When explicitly given the name of a non-existent file or directory, it
implies that the file exists and matches the repository:
julianfoad@linux:~/src/subversion ls blah
ls: blah: No such file or directory
julianfoad@linux:~/src/subversion svn status blah
blah
julianfoad@linux:~/src/subversion svn status blah/
blah
julianfoad@linux:~/src/subversion svn status blah/blah
subversion/libsvn_wc/lock.c:289: (apr_err=155006)
svn: Invalid lock
svn: lock path is not a directory (blah)
julianfoad@linux:~/src/subversion
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>> > Hmm, svn:ignore is used to control the display of non-versioned
>> > files. Such files cannot be added, modified etc.
>>
>>Oh, yes they can! Be added, that is. They then become versioned and
>>can be changed, etc.
>
> Once added they are no longer ignored.
Ah, OK. I was thinking "ignored" meant "in the ignore list", but now I
understand it means "in the ignore list and not versioned". Sorry it
took me a while to understand that. So, going back to the original
comments:
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>I don't think a main status flag of "I" would be correct for ignored
>>items. "Ignored" is orthogonal meta-data; the status of an ignored item
>>can still be " ", "A", "D", "M", etc. just as for a non-ignored item.
>
> That was the subject of an earlier change. It was deemed necessary to
> be able to distinguish between ignored and non-ignored items.
So although the ignore list is orthogonal to (independent of) the
status, the "ignored" condition is not. The proposal was just to
display "I" instead of "?"; the characters displayed for other statuses
would not be affected. That makes sense and I have no objection.
>> It may not be what "ignore" was originally
>>intended for, but it could perhaps be useful sometimes, if it were to
>>have well-defined semantics. (In particular, should the "ignore"
>>directive be ignored for versioned files?
>
> It is, as far as I know. Do you have a counter-example?
No. Was just not sure whether the behaviour was defined. It probably
is in the book.
I have to go to bed now. Perhaps my brain will work better tomorrow :-)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> > Hmm, svn:ignore is used to control the display of non-versioned
> > files. Such files cannot be added, modified etc.
>
> Oh, yes they can! Be added, that is. They then become versioned and
> can be changed, etc.
Once added they are no longer ignored.
> It may not be what "ignore" was originally
> intended for, but it could perhaps be useful sometimes, if it were to
> have well-defined semantics. (In particular, should the "ignore"
> directive be ignored for versioned files?
It is, as far as I know. Do you have a counter-example?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>> > That was the subject of an earlier change. It was deemed necessary
>> >to be able to distinguish between ignored and non-ignored items.
>>
>>Are we talking about the main status flag (first column)? If so, how
>>do you then distinguish between ignored-added, ignored-deleted,
>>ignored-modified, ignored-unchanged etc.?
>
> Hmm, svn:ignore is used to control the display of non-versioned
> files. Such files cannot be added, modified etc.
Oh, yes they can! Be added, that is. They then become versioned and
can be changed, etc. It may not be what "ignore" was originally
intended for, but it could perhaps be useful sometimes, if it were to
have well-defined semantics. (In particular, should the "ignore"
directive be ignored for versioned files? Should the combination be
disallowed?) At least, it's worth thinking about how
"ignored/not-ignored" interacts (or should not interact) with
"versioned/non-versioned".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> > That was the subject of an earlier change. It was deemed necessary
> >to be able to distinguish between ignored and non-ignored items.
>
> Are we talking about the main status flag (first column)? If so, how
> do you then distinguish between ignored-added, ignored-deleted,
> ignored-modified, ignored-unchanged etc.?
Hmm, svn:ignore is used to control the display of non-versioned
files. Such files cannot be added, modified etc.
> Actually, I don't see "I".
> Do you mean this "I" was added at some time but has since been
> removed?
It hasn't been implemented yet, it's a proposal.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>I don't think a main status flag of "I" would be correct for ignored
>>items. "Ignored" is orthogonal meta-data; the status of an ignored item
>>can still be " ", "A", "D", "M", etc. just as for a non-ignored item.
>
> That was the subject of an earlier change. It was deemed necessary to
> be able to distinguish between ignored and non-ignored items.
Are we talking about the main status flag (first column)? If so, how do
you then distinguish between
ignored-added, ignored-deleted, ignored-modified, ignored-unchanged
etc.? Actually, I don't see "I". Do you mean this "I" was added at
some time but has since been removed? I see this (for a controlled file
and an uncontrolled file):
~/src/subversion> svn ps svn:ignore 'HACKING
> configure
> ' .
property `svn:ignore' set on ''
~/src/subversion> svn status HACKING configure
HACKING
? configure
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> I don't think a main status flag of "I" would be correct for ignored
> items. "Ignored" is orthogonal meta-data; the status of an ignored item
> can still be " ", "A", "D", "M", etc. just as for a non-ignored item.
That was the subject of an earlier change. It was deemed necessary to
be able to distinguish between ignored and non-ignored items.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Julian Foad <ju...@btopenworld.com>.
Karl Fogel wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>- Verbose mode and recursive mode both list uncontrolled files, but do
>>not list uncontrolled directories.
>
> That's certainly questionable, yah.
Oh dear, my error again. It does in fact list them; the directories I
was looking at must have been in the "ignore" list. Sorry for wasting
time there.
>>- When explicitly given the name of an uncontrolled directory, it
>>fails and exits without continuing the report:
>
> That last one is just an outright bug, considering the effect it has
> when one passes "*" as an argument. Can you file an issue for it?
> You might want to link it with issue #1076, not in a dependency way,
> just in a "these are all in the same domain" sort of way.
OK, done. Issue number 1124.
>>julianfoad@linux:~/src/subversion> svn status blah/blah
>>subversion/libsvn_wc/lock.c:289: (apr_err=155006)
>>svn: Invalid lock
>>svn: lock path is not a directory (blah)
>>julianfoad@linux:~/src/subversion>
>
> This behavior is probably okay, because it could never be the result
> of a "*" expansion -- the user has named a file that not only doesn't
> exist, but couldn't exist.
I agree that an error message is OK for this third case, and exactly
what the error message says is not so important. This corner case is
similar to that described by Philip Martin in issue 1076 as:
> Target does not exist and is not versioned:
>
> $ svn status foo
> ../svn/subversion/libsvn_subr/io.c:1802: (apr_err=2)
> svn: No such file or directory
> svn: svn_io_file_open: can't open `.svn/entries'
In both of these cases, the directory containing the requested item is
not itself under version control. (In a controlled directory, a target
that does not exist and is not versioned is handled correctly with a "?".)
I cannot see how to add comments to an issue; I would have put the above
into issue 1076 and also the following:
I don't think a main status flag of "I" would be correct for ignored
items. "Ignored" is orthogonal meta-data; the status of an ignored item
can still be " ", "A", "D", "M", etc. just as for a non-ignored item.
I feel that explicit arguments should be treated the same way as items
found by the implicit expansion of a directory. In particular, that
they should not be displayed at all if they match the "ignored" list.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Julian Foad <ju...@btopenworld.com> writes:
> > I tried
> > setting "Reply-to" to point back to the list in a message that I sent,
> > because I don't want to receive two copies of each reply, but the list
> > server removed it. Some people (including you, Karl) specify a
> > Reply-to which is a personal address different from the address you
> > send from, and the list server removes that too. That seems a bit
> > sub-optimal.
>
> Huh? Our list server is supposed to not touch Reply-to. If mine is
> getting munged, how do you know that I set it? :-) Are you sure you
> saw what you saw?
Well, I'll be darned. I just went back and looked at some posts from
me, and even though I explicitly set `Reply-to' to kfogel@collab.net
in every message I send, my posts here have no Reply-to header at all.
Apparently this is happening to others too.
Is our list software removing `Reply-to' entirely? Our goal was to
simply leave it alone, not demolish it :-).
Daniel (Rall), do you by any chance know how to check what's happening
with the mailing list software on tigris.org?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Julian Foad <ju...@btopenworld.com> writes:
> Yes. I have just noticed and re-sent.
>
> I'm not used to mailing lists that don't munge Reply-to to point to
> the list. My mail client, Mozilla, doesn't have a "Reply to mailing
> list" function, so I have to remember to use "Reply all" (do you want
> to receive a personal copy as well as the one to the list?) or change
> the "To" address manually. Is there a policy on Reply-to?
Yes, the policy is not to munge it. If you Google on "Reply-to
Munging Considered Harmful" you'll see why. There are also documents
explaining the opposite point of view. This list did not have perfect
agreement on the question, but the informal consensus was that more
people thought munging bad than good.
> I tried
> setting "Reply-to" to point back to the list in a message that I sent,
> because I don't want to receive two copies of each reply, but the list
> server removed it. Some people (including you, Karl) specify a
> Reply-to which is a personal address different from the address you
> send from, and the list server removes that too. That seems a bit
> sub-optimal.
Huh? Our list server is supposed to not touch Reply-to. If mine is
getting munged, how do you know that I set it? :-) Are you sure you
saw what you saw?
As for duplicates, your mail client might have an option to fold them
into one.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Julian Foad <ju...@btopenworld.com>.
Karl Fogel wrote:
> Hey, Julian, did you mean to send this to the whole list? It only
> went to me...
Yes. I have just noticed and re-sent.
I'm not used to mailing lists that don't munge Reply-to to point to the
list. My mail client, Mozilla, doesn't have a "Reply to mailing list"
function, so I have to remember to use "Reply all" (do you want to
receive a personal copy as well as the one to the list?) or change the
"To" address manually. Is there a policy on Reply-to? I tried setting
"Reply-to" to point back to the list in a message that I sent, because I
don't want to receive two copies of each reply, but the list server
removed it. Some people (including you, Karl) specify a Reply-to which
is a personal address different from the address you send from, and the
list server removes that too. That seems a bit sub-optimal.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn status handling uncontrolled and non-existant files
Posted by Karl Fogel kf...@newton.ch.collab.net.
Julian Foad julianfoad@btopenworld.com writes:
- Verbose mode and recursive mode both list uncontrolled files, but do
not list uncontrolled directories.
That's certainly questionable, yah.
- When explicitly given the name of an uncontrolled file, it lists its
status as ?, as expected.
- When explicitly given the name of an uncontrolled directory, it
fails and exits without continuing the report:
That last one is just an outright bug, considering the effect it has
when one passes * as an argument. Can you file an issue for it?
You might want to link it with issue #1076, not in a dependency way,
just in a these are all in the same domain sort of way.
julianfoad@linux:~/src/subversion svn status *
A A_NEW_DIR
BUGS
CHANGES
COMMITTERS
COPYING
HACKING
IDEAS
INSTALL
? Makefile
Makefile.in
PORTING
README
subversion/libsvn_wc/status.c:718: (apr_err=155007)
svn: Path is not a working copy directory
svn: svn_wc_statuses: apr is not a working copy directory
- When explicitly given the name of a non-existent file or directory,
it implies that the file exists and matches the repository:
julianfoad@linux:~/src/subversion ls blah
ls: blah: No such file or directory
julianfoad@linux:~/src/subversion svn status blah
blah
julianfoad@linux:~/src/subversion svn status blah/
blah
julianfoad@linux:~/src/subversion svn status blah/blah
subversion/libsvn_wc/lock.c:289: (apr_err=155006)
svn: Invalid lock
svn: lock path is not a directory (blah)
julianfoad@linux:~/src/subversion
This behavior is probably okay, because it could never be the result
of a * expansion -- the user has named a file that not only doesn't
exist, but couldn't exist. The error message is a bit cryptic, but
that would be helped by quotation marks (as in revision 4599). I have
added some.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn status" handling uncontrolled and non-existant files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Julian Foad <ju...@btopenworld.com> writes:
> - Verbose mode and recursive mode both list uncontrolled files, but do
> not list uncontrolled directories.
That's certainly questionable, yah.
> - When explicitly given the name of an uncontrolled file, it lists its
> status as "?", as expected.
>
> - When explicitly given the name of an uncontrolled directory, it
> fails and exits without continuing the report:
That last one is just an outright bug, considering the effect it has
when one passes "*" as an argument. Can you file an issue for it?
You might want to link it with issue #1076, not in a dependency way,
just in a "these are all in the same domain" sort of way.
> julianfoad@linux:~/src/subversion> svn status *
> A A_NEW_DIR
> BUGS
> CHANGES
> COMMITTERS
> COPYING
> HACKING
> IDEAS
> INSTALL
> ? Makefile
> Makefile.in
> PORTING
> README
> subversion/libsvn_wc/status.c:718: (apr_err=155007)
> svn: Path is not a working copy directory
> svn: svn_wc_statuses: apr is not a working copy directory
>
> - When explicitly given the name of a non-existent file or directory,
> it implies that the file exists and matches the repository:
>
> julianfoad@linux:~/src/subversion> ls blah
> ls: blah: No such file or directory
> julianfoad@linux:~/src/subversion> svn status blah
> blah
> julianfoad@linux:~/src/subversion> svn status blah/
> blah
> julianfoad@linux:~/src/subversion> svn status blah/blah
> subversion/libsvn_wc/lock.c:289: (apr_err=155006)
> svn: Invalid lock
> svn: lock path is not a directory (blah)
> julianfoad@linux:~/src/subversion>
This behavior is probably okay, because it could never be the result
of a "*" expansion -- the user has named a file that not only doesn't
exist, but couldn't exist. The error message is a bit cryptic, but
that would be helped by quotation marks (as in revision 4599). I have
added some.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org