You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/07/12 16:13:56 UTC
Re: svn commit: rev 2485 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client
kevin@tigris.org writes:
> This means that we will get an error if 'svn:executable' is set, edited, or
> deleted from a directory in the non-recursive case. In the recursive case
> directories will be silently ignored, and the operation will be performed on
> the files only. Is this behaviour acceptable to everyone?
Why would we prohibit deletions? Then our "good" client can't even
repair lossage caused by "bad" clients... :-)
If the policy is that the property is not allowed on dirs, then we
should allow removing it from dirs where it already exists, IMHO.
> Modified: trunk/subversion/libsvn_client/prop_commands.c
> ==============================================================================
> --- trunk/subversion/libsvn_client/prop_commands.c (original)
> +++ trunk/subversion/libsvn_client/prop_commands.c Fri Jul 12 10:47:16 2002
> if (current_entry->kind == svn_node_dir && current_entry_name)
Gack. I know this isn't your code, but we should parenthesize this
for clear precedence. (Clear to humans, I mean.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2485 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> Right. Coming up!
Thanks!
You are indeed Mr. Bug Killer today, it is a sight to see...
Btw, Ben points out that my example fix was wrong:
> if ((kind == svn_node_dir) && (value == NULL))
should have been
> if ((kind == svn_node_dir) && (value != NULL))
right?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2485 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Jul 12, 2002 at 11:24:19AM -0500, Karl Fogel wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > > Why would we prohibit deletions? Then our "good" client can't even
> > > repair lossage caused by "bad" clients... :-)
> >
> > Well, all property changes are done via svn_wc_prop_set. Deletions just make
> > the value arg NULL. It could be changed to do as you suggest, but I didn't
> > really see the need. If we were post-1.0 maybe...
>
> Okay. So the value is NULL to signal deletion. That's how we
> implemented deletion internally -- the point is that the user is
> deleting the property. It's pretty easy to put a conditional in to
> *allow* the deletion of the property even when kind == svn_node_dir.
> Just change
>
> if (kind == svn_node_dir)
>
> to
>
> if ((kind == svn_node_dir) && (value == NULL))
>
> no?
>
> I mean, we're not talking about some deep theoretical problem here :-).
>
Right. Coming up!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: svn commit: rev 2485 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Why would we prohibit deletions? Then our "good" client can't even
> > repair lossage caused by "bad" clients... :-)
>
> Well, all property changes are done via svn_wc_prop_set. Deletions just make
> the value arg NULL. It could be changed to do as you suggest, but I didn't
> really see the need. If we were post-1.0 maybe...
Okay. So the value is NULL to signal deletion. That's how we
implemented deletion internally -- the point is that the user is
deleting the property. It's pretty easy to put a conditional in to
*allow* the deletion of the property even when kind == svn_node_dir.
Just change
if (kind == svn_node_dir)
to
if ((kind == svn_node_dir) && (value == NULL))
no?
I mean, we're not talking about some deep theoretical problem here :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2485 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Jul 12, 2002 at 11:13:56AM -0500, Karl Fogel wrote:
> kevin@tigris.org writes:
> > This means that we will get an error if 'svn:executable' is set, edited, or
> > deleted from a directory in the non-recursive case. In the recursive case
> > directories will be silently ignored, and the operation will be performed on
> > the files only. Is this behaviour acceptable to everyone?
>
> Why would we prohibit deletions? Then our "good" client can't even
> repair lossage caused by "bad" clients... :-)
Well, all property changes are done via svn_wc_prop_set. Deletions just make
the value arg NULL. It could be changed to do as you suggest, but I didn't
really see the need. If we were post-1.0 maybe...
>
> If the policy is that the property is not allowed on dirs, then we
> should allow removing it from dirs where it already exists, IMHO.
>
> > Modified: trunk/subversion/libsvn_client/prop_commands.c
> > ==============================================================================
> > --- trunk/subversion/libsvn_client/prop_commands.c (original)
> > +++ trunk/subversion/libsvn_client/prop_commands.c Fri Jul 12 10:47:16 2002
> > if (current_entry->kind == svn_node_dir && current_entry_name)
>
> Gack. I know this isn't your code, but we should parenthesize this
> for clear precedence. (Clear to humans, I mean.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~