C and C++ programs do not use the "um" command internally. They use
"unlink", which is what the "rm" commad uses internally, which I see
scattered throughout the source code. C functions are not going to be
interactive unless someone actually programs in a deliberate
interaction.
That said, I can
On 11/19/2013 6:28 PM, Ryan Schmidt wrote:
On Nov 18, 2013, at 10:37, Rick Varney wrote:
So for Redhat 5, rm does seem to give read-only files some special
treatment. The fact that rm on your OS does not makes me wonder if I am
wrong about how typical this behavior is in other Linux/Unix flavo
On Nov 18, 2013, at 10:37, Rick Varney wrote:
> So for Redhat 5, rm does seem to give read-only files some special
> treatment. The fact that rm on your OS does not makes me wonder if I am
> wrong about how typical this behavior is in other Linux/Unix flavors.
Both GNU rm (used on Linux) and BS
Branko Čibej wandisco.com> writes:
>
> Maybe this behavior can be made optional, enabled via the
> configuration file?
>
> Changing client behaviour via config file options is almost always a
> bad idea ... every such option makes testing more complex and bug
> triag
David Chapman acm.org> writes:
>
> On 11/15/2013 3:57 PM, Rick Varney wrote:
> > Branko Čibej wandisco.com> writes:
> >
> >>
> >> It really depends on what you think "Unix rm" actually is. The
> >> unlink() or remove() functions don't care about permissions on the
> >> target
On 16.11.2013 00:57, Rick Varney wrote:
> Branko Čibej wandisco.com> writes:
>
>>
>> You're allowed to modify and commit changes to a file that has the
>> svn:needs-lock property regardless of whether it's locked or not.
>> svn:needs-lock is not a constraint, it's just a reminder.
On 11/15/2013 3:57 PM, Rick Varney wrote:
Branko Čibej wandisco.com> writes:
It really depends on what you think "Unix rm" actually is. The
unlink() or remove() functions don't care about permissions on the
target, only that you have write permission on the parent directory.
Branko Čibej wandisco.com> writes:
>
>
> On 15.11.2013 20:30, Rick Varney wrote:
>
>
> Branko Čibej wandisco.com> writes:
>
>
>
> I disagree with the behaviour change because it makes 'svn
>
>
> delete' in
>
>
> the prese
On 15.11.2013 20:30, Rick Varney wrote:
> Branko Čibej wandisco.com> writes:
>
>> I disagree with the behaviour change because it makes 'svn
> delete' in
>> the presence of svn:needs-lock behave exactly opposite to every other
>> command. IMO, it's quite enough to simply fix the bug wher
Branko Čibej wandisco.com> writes:
> I disagree with the behaviour change because it makes 'svn
delete' in
> the presence of svn:needs-lock behave exactly opposite to every other
> command. IMO, it's quite enough to simply fix the bug where we try to
> change the permissions on a non-ex
On 14.11.2013 21:54, Branko Čibej wrote:
> On 14.11.2013 21:44, Philip Martin wrote:
>> Branko Čibej writes:
>>
>>> On 14.11.2013 19:24, Rick Varney wrote:
We are currently on Subversion 1.6.6.
What do you think? Any alternatives I have not considered? Should I
open a feature requ
On 14.11.2013 21:44, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 14.11.2013 19:24, Rick Varney wrote:
>>> We are currently on Subversion 1.6.6.
>>> What do you think? Any alternatives I have not considered? Should I
>>> open a feature request for this?
>> I disagree with the behaviour ch
Branko Čibej writes:
> On 14.11.2013 19:24, Rick Varney wrote:
>> We are currently on Subversion 1.6.6.
>> What do you think? Any alternatives I have not considered? Should I
>> open a feature request for this?
>
> I disagree with the behaviour change because it makes 'svn delete' in
> the pre
On 14.11.2013 19:24, Rick Varney wrote:
> Hello,
>
> At my company we are using the lock-modify-unlock model, with the
> svn:needs-lock property set on most files. We have a pre-commit hook
> that prevents committing unlocked files. We are currently on
> Subversion 1.6.6.
>
> Here is a typical fr
14 matches
Mail list logo
