On 2 February 2012 18:26, Maureen Barger wrote:
> Hello - in creating an iteration in Subversion 1.5.1 I inadvertently deleted
> the source after I created the new iteration. I was able to rename the new
> iteration to the old, but in the process lost the branches directory. I have
> a backup from
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
Hi,
I've had a request to restrict access to revisions of certain SVN projects in a
repository older than a set revision number. My repo is accessed via Apache
HTTPS. Has anybody had any experience of this or would know where to start? I'm
guessing it could be possible in the httpd config to de
Bump!
On 30 January 2012 16:08, Jon Hardcastle wrote:
> Hi,
>
> I have an issue where by i am trying to merge a directory structure from a
> into b.
>
> One of the changes in that structure is that a directory that is already
> present in b has been deleted and re-added in a.
>
> Hence I am tryin
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
Hello, Ulrich
> Am 02.02.2012 08:37, schrieb Ignacio González (Eliop):
>
>> What I was really surprised is to see that the filenames flowing through the
>> communication channel is not normalised (well, that is just speculation,
>> am I wrong?). Is there a way to force the clients to convert the n
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
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 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:
> 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 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
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
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 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
Boa tarde,
Preciso saber se o software Subversion é free para Windows 2003 e uso
corporativo?
Obrigado,
Roberto Revilla
Tecnologia da Informação
Avibras Ind.Aeroespacial S/A
(12) 3955.6013
_
On Fri, 3 Feb 2012 12:39:18 -0300
wrote:
> Boa tarde,
>
> Preciso saber se o software Subversion é free para Windows 2003 e uso
> corporativo?
Ich will ja nicht unhöflich sein, aber Englisch ist sonst die Sprache
der Wahl, wenn man international kommuniziert. Auf Protugisisch wirst
du leider
On Fri, Feb 3, 2012 at 10:01 AM, Attila Kinali wrote:
> On Fri, 3 Feb 2012 12:39:18 -0300
> wrote:
>
>> Boa tarde,
>>
>> Preciso saber se o software Subversion é free para Windows 2003 e uso
>> corporativo?
>
> Ich will ja nicht unhöflich sein, aber Englisch ist sonst die Sprache
> der Wahl, wen
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 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
I would think those two mergeinfos were equivalent, so mergeinfo elision
should remove the mergeinfo on "live/templates/c-physignathus".
# svn propget svn:mergeinfo live
/cm_dev:99-344
/dev:367-578,580
# svn propget svn:mergeinfo live/templates/c-physignathus
/cm_dev/templates/c-physignathus:99-3
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 Fri, Feb 03, 2012 at 04:45:17PM +0100, André Hänsel wrote:
> I would think those two mergeinfos were equivalent, so mergeinfo elision
> should remove the mergeinfo on "live/templates/c-physignathus".
>
> # svn propget svn:mergeinfo live
> /cm_dev:99-344
> /dev:367-578,580
>
> # svn propget svn
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
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.
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 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
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 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 Feb 3, 2012, at 06:14, Chris Evans wrote:
> I've had a request to restrict access to revisions of certain SVN projects in
> a repository older than a set revision number. My repo is accessed via Apache
> HTTPS. Has anybody had any experience of this or would know where to start?
> I'm guess
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 Fri, Feb 3, 2012 at 12:47 PM, Ryan Schmidt
wrote:
>
> On Feb 3, 2012, at 06:14, Chris Evans wrote:
>
>> I've had a request to restrict access to revisions of certain SVN projects
>> in a repository older than a set revision number. My repo is accessed via
>> Apache HTTPS. Has anybody had any
31 matches
Mail list logo
