On Feb 3, 2012, at 11:23, Johan Holmberg wrote:
> But even if I don't understand exactly why I had these problems, they are
> solved now (as I wrote in the previous mail).
The Subversion client is responsible for normalizing keywords and eol styles
before sending the changes to the repository
On 02/03/2012 05:57 PM, Stefan Sperling wrote:
On Fri, Feb 03, 2012 at 05:33:11PM +0100, Johan Holmberg wrote:
But here my working copy files are already UNIX text files (no \r\n
line endings).
Your working files might already be normalised according to the
setting of svn:eol-style, and therefo
On 02/03/2012 05:54 PM, Philip Martin wrote:
Johan Holmberg writes:
A similar problem here, the file in the repository should have \n line
endings but the file has some \r\n line endings. Once again committing
the file should fix the problem (although mixed line endings may cause
the commit t
On Fri, Feb 03, 2012 at 05:33:11PM +0100, Johan Holmberg wrote:
> But here my working copy files are already UNIX text files (no \r\n
> line endings).
Your working files might already be normalised according to the
setting of svn:eol-style, and therefore not show mixed eols.
Philip meant the fil
Johan Holmberg writes:
>> A similar problem here, the file in the repository should have \n line
>> endings but the file has some \r\n line endings. Once again committing
>> the file should fix the problem (although mixed line endings may cause
>> the commit to fail and require you to make them
On 02/03/2012 04:57 PM, Philip Martin wrote:
Johan Holmberg writes:
Yes, in one case I get a difference for the $Id$ line (from "svn diff"):
-$Id:$
+$Id$
OK. I think the file in the repository has '$Id:$' instead of '$Id$' for
the keyword. Committing the file should fix the problem.
On Fri, Feb 03, 2012 at 04:23:35PM +0100, Johan Holmberg wrote:
> I would like to try it with Subversion 1.7. How do I get a binary
> for Ubuntu 10.10 or 11.10? I couldn't find any precompiled packages
> easily. Or do I have to build it from source?
I don't think Ubuntu is shipping Subversion 1.7
Johan Holmberg writes:
> Yes, in one case I get a difference for the $Id$ line (from "svn diff"):
>
> -$Id:$
> +$Id$
OK. I think the file in the repository has '$Id:$' instead of '$Id$' for
the keyword. Committing the file should fix the problem.
> and in the other files the "svn diff" sho
On 02/03/2012 03:23 PM, Stefan Sperling wrote:
On Fri, Feb 03, 2012 at 03:04:54PM +0100, Johan Holmberg wrote:
On 02/03/2012 02:50 PM, Philip Martin wrote:
I have now done some further experiments. I just issued commands like this:
$ svn status # no modified files reported
Su
On 02/03/2012 03:22 PM, Philip Martin wrote:
Johan Holmberg writes:
On 02/03/2012 02:50 PM, Philip Martin wrote:
I have now done some further experiments. I just issued commands like this:
$ svn status # no modified files reported
Subversion is not doing a full text compar
On Fri, Feb 03, 2012 at 03:04:54PM +0100, Johan Holmberg wrote:
> On 02/03/2012 02:50 PM, Philip Martin wrote:
> >
> >I have now done some further experiments. I just issued commands like this:
> >
> > $ svn status # no modified files reported
> >Subversion is not doing a full text
Johan Holmberg writes:
> On 02/03/2012 02:50 PM, Philip Martin wrote:
>>
>> I have now done some further experiments. I just issued commands like this:
>>
>> $ svn status # no modified files reported
>> Subversion is not doing a full text comparison because the timestamps
>> mat
On 02/03/2012 02:50 PM, Philip Martin wrote:
I have now done some further experiments. I just issued commands like this:
$ svn status # no modified files reported
Subversion is not doing a full text comparison because the timestamps
match. So the difference that is present is
On Fri, Feb 03, 2012 at 01:58:08PM +0100, Johan Holmberg wrote:
> So I don't think saying "If that timestamp differs from the one on
> disk, the file is considered modified." is correct. "svn" does not
> work like that for me at least.
Right. I misremembered how this works.
Thanks to Philip for co
Johan Holmberg writes:
> On 02/03/2012 02:09 PM, Philip Martin wrote:
>> Johan Holmberg writes:
>>
>>> So I don't think saying "If that timestamp differs from the one on
>>> disk, the file is considered modified." is correct. "svn" does not
>>> work like that for me at least.
>> You are correct,
On 02/03/2012 02:09 PM, Philip Martin wrote:
Johan Holmberg writes:
So I don't think saying "If that timestamp differs from the one on
disk, the file is considered modified." is correct. "svn" does not
work like that for me at least.
You are correct, that is not how Subversion behaves. Subve
Johan Holmberg writes:
> So I don't think saying "If that timestamp differs from the one on
> disk, the file is considered modified." is correct. "svn" does not
> work like that for me at least.
You are correct, that is not how Subversion behaves. Subversion checks
the timestamp to determine wh
On 02/03/2012 01:28 PM, Stefan Sperling wrote:
On Fri, Feb 03, 2012 at 12:47:57PM +0100, Johan Holmberg wrote:
Is Subversion really sensitive to such timestamp differences?
Yes, it is. To avoid checking the entire content of all files in the
working copy every time you run 'svn diff' or 'svn st
On Fri, Feb 03, 2012 at 12:47:57PM +0100, Johan Holmberg wrote:
> Is Subversion really sensitive to such timestamp differences?
Yes, it is. To avoid checking the entire content of all files in the
working copy every time you run 'svn diff' or 'svn status', Subversion
keeps a record of the timestam
Hi!
I get some strange reports of differences from "svn diff" and "svn
status" after doing the following operations:
$ svn co http://somehost/somepath proj
$ rsync -a proj proj-rsync-copy
$
$ svn status proj-rsync-copy
... reports modified files ...
$ svn status proj
20 matches
Mail list logo
