On 2019-03-07 17:50:26 +0100, Branko Čibej wrote:
> On 07.03.2019 17:36, Vincent Lefevre wrote:
> > On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
> >> I had this problem once when I ran a recursive sed command over my
> >> working copy, not considering that it would modify the contents of
> >>
On 07.03.2019 17:36, Vincent Lefevre wrote:
> On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
>> I had this problem once when I ran a recursive sed command over my
>> working copy, not considering that it would modify the contents of
>> the .svn directory too.
> Would it be a good idea to protect
On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
> I had this problem once when I ran a recursive sed command over my
> working copy, not considering that it would modify the contents of
> the .svn directory too.
Would it be a good idea to protect the .svn directory by default?
I mean that Subver
On Mar 6, 2019, at 09:44, Satya Mishra wrote:
> On Tue, Mar 5, 2019 at 11:39 PM Ryan Schmidt wrote:
>> On Mar 5, 2019, at 12:23, Satya Mishra wrote:
>>
>>> I recently encountered a strange problem while trying to revert a failed
>>> experiment. svn revert apparently succeeded, but kept giving
Indeed the pristines had been modified. I didn't directly touch them
myself. I only worked on the files in the working copy.
This is clearly the incorrect file.
> sha1sum .svn/pristine/6c/6c0ff2498b56833e603908a66a284351ad0ec7dc.svn-base
c58a4e654e2e8ac565e9705a7f83901a3ea7e321
.svn/pristine/6c/6c
On Mar 5, 2019, at 12:23, Satya Mishra wrote:
> I recently encountered a strange problem while trying to revert a failed
> experiment. svn revert apparently succeeded, but kept giving me the
> unreverted files. Example shell output showing the problem is below. The
> sha1sum of the file doesn't
Thanks a lot for the suggestion. This is a binary file. I double checked
the properties (output below signature)
I also noticed another thread titled " E155011 + E160013: how to clear this
mess? " which seems to be a similar issue. But svn up --set-depth empty,
which worked for the other user, did
Possibly a line-ending conversion?
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
Check to see if the svn:eol-style property is set.
Eric
On Tue, Mar 5, 2019 at 10:34 AM Satya Mishra wrote:
> Hi,
>
> I recently encountered
Hi,
I recently encountered a strange problem while trying to revert a failed
experiment. svn revert apparently succeeded, but kept giving me the
unreverted files. Example shell output showing the problem is below. The
sha1sum of the file doesn't match the sha1sum from repo in this working
copy. Bu