Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 12:51:13 +0100, Philip Martin wrote: > If you are saying that a move should update the LastChangedRev of every > file (and dir?) in the destination then that would break the cheap copy > feature of Subversion's copy-on-write filesystem. Anyway the URL of every file should be updated,

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote: > So I believe that 1.6's behavior in the working copy is indeed > incorrect, and that the LCR of a child was always intended to be > unaffected by the move/copy of a parent dir. That's the behavior of > the repository, in both 1.6 and 1.7. What

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-03 13:21:35 +0200, Johan Corveleyn wrote: > I just tested my scenario with 1.6: it doesn't have the same issue > (subdir has LastChangedRev 3 in both the working copy and the > repository). So this is a regression in 1.7. The reason why "subdir" has LastChangedRev 3 may be because its p

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-03 13:15:33 +0200, Johan Corveleyn wrote: > No, it's not the same issue (the issue you reported is, let's say, > open for discussion, and I don't think the 1.7 behavior is wrong ... > it's just different from 1.6). OK, I actually focused on "svn info .../subdir", where you get "Last Cha

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-06-27 16:33:23 +0200, Johan Corveleyn wrote: > I noticed this while investigating (other) problems with incorrect > LastChangedRev's (subtle form of working copy corruption): It seems to be the same thing I had reported here: http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.

Re: Bigger --deltas dump with 1.7.5 than with 1.6.17

Thanks for the explanations. On 2012-06-22 00:18:50 +0200, Stefan Fuhrmann wrote: > xdelta uses fixed-size 100kByte deltification windows. > The Changelog file in question is >400k, i.e. 4+ windows. > You insert about 2k at the beginning of the file, moving > the older parts by a similar distance.

Re: Bigger --deltas dump with 1.7.5 than with 1.6.17

On 2012-06-20 02:48:23 +0200, Vincent Lefevre wrote: > On 2012-06-19 19:41:51 +0300, Daniel Shahaf wrote: > > I assume that the binary svndiff chunks are different, right? > > Yes, the binary svndiff chunks are different and have the declared > size. But why is 1.6.17 better th

Re: Bigger --deltas dump with 1.7.5 than with 1.6.17

On 2012-06-19 19:41:51 +0300, Daniel Shahaf wrote: > I assume that the binary svndiff chunks are different, right? Yes, the binary svndiff chunks are different and have the declared size. But why is 1.6.17 better than 1.7.5? -- Vincent Lefèvre - Web: 100% accessible val

Bigger --deltas dump with 1.7.5 than with 1.6.17

After comparing two dumps of the same repository, one obtained with Subversion 1.6.17 and one obtained with 1.7.5, both with --incremental --deltas (both from revision 0, but not with the same upper revision), I've noticed two changes: 1. The properties are reordered (that was expected after the c

Re: incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

On 2012-06-19 11:53:37 +0200, Stefan Sperling wrote: > On Tue, Jun 19, 2012 at 09:46:20AM +0200, Vincent Lefevre wrote: > > On 2012-06-19 01:29:18 -0400, Greg Stein wrote: > > > In 1.6, we erroneously used the containing directory's revision for the > > > file in ce

Re: incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

On 2012-06-19 01:29:18 -0400, Greg Stein wrote: > In 1.6, we erroneously used the containing directory's revision for the > file in certain cases. 1.7 is correct: the file is not changed until r4. > Maybe the directory has, but that is independent of the file. But in this case, is it normal that r

incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

I've upgraded Subversion from 1.6.17 to 1.7.5 (Debian/unstable). And there's the following problem: Subversion 1.7.5 no longer notices a change of revision of some file when a parent directory has been moved. In particular, this yields incorrect keyword expansion. The bug can be reproduced with t

Re: Let's discuss about unicode compositions for filenames!

On 2012-02-17 13:54:35 +0900, Hiroaki Nakamura wrote: > Actually, whether filename is in NFC or NFD depends on the way of > inputting filenames. > If you type all characters, it is in NFC. No, or actually, perhaps this depends on the user configuration (e.g. keyboard configuration / input method).

Re: Let's discuss about unicode compositions for filenames!

On 2012-01-30 21:29:41 +0100, Stefan Sperling wrote: > On Mon, Jan 30, 2012 at 09:09:22PM +0100, Branko Čibej wrote: > > Are you seriously proposing that we /support/ such broken, hackish > > nonsense? How do you expect users to tell the difference between file > > names that look identical on the

Re: format of svn:author

On 2012-01-03 15:44:47 +0100, Branko Čibej wrote: > I think this whole thread is slightly bogus. It should be obvious that > whatever is in the svn:author field has better be a unique identifier of > the person responsible for the commit, regardless of how it gets there. I'd say that this choice s

Re: Bug: "svnadmin dump --incremental --deltas" gives too much output

On 2011-12-26 00:51:51 +0100, Vincent Lefevre wrote: > Actually the --incremental option doesn't matter. For instance, it > is not useful when doing a dump from revision 0, and I get exactly > the same bug, as said below. [...] I forgot to say that I did these tests with Sub

Re: Bug: "svnadmin dump --incremental --deltas" gives too much output

On 2009-01-06 23:00:40 +0100, Vincent Lefevre wrote: > On 2009-01-06 11:20:20 -0500, C. Michael Pilato wrote: > > I've been sitting on this thread for a long time. Still no time to > > really invest here, but I filed issue #3353 so we don't lose this discussion

Recursive deletion of property throws unnecessary warning

I got the following warning with: svn pdel -R svn:eol-style . svn: Attempting to delete nonexistent property 'svn:eol-style' using svn 1.6.17, and exit status 1. I think this should be regarded as a bug. I've searched with Google and found that this problem is not new: http://svn.haxx.se/dev/a

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On 2011-05-30 16:27:04 +0200, Stefan Sperling wrote: > please feel free to file an issue on this bug. OK: http://subversion.tigris.org/issues/show_bug.cgi?id=3906 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On 2011-05-30 09:58:45 -0400, Mark Phippard wrote: > 2011/5/30 Vincent Lefevre : > > I've found the following bug with Subversion 1.6.16: > > > >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025 > > > > The problem is: With the svn+ssh scheme, a s

svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

I've found the following bug with Subversion 1.6.16: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025 The problem is: With the svn+ssh scheme, a ssh process is started and sets its stderr to non-blocking mode. When executing an API-based svn client with both stdout and stderr redirected

Obsolete URL on subversion.tigris.org

Hi, When one searches for Subversion history on Google, one gets: http://subversion.tigris.org/release-history.html This page says: This information has been moved to http://subversion.apache.org/release-history.html but here one gets a 404 Not Found error. The correct URL should be giv

Re: svn diff - Is this behaviour expected?

On 2010-08-15 23:30:09 -0700, Bert Huijben wrote: > > BTW, the local pristine version does correspond to some revision > > in the repository. It shouldn't be mixed up with the working copy > > version. > > What if the file is a copy? In my example, it wasn't a copy. But... > In that case BASE re

Re: svn diff - Is this behaviour expected?

On 2010-08-15 05:34:08 -0700, Bert Huijben wrote: > > Conversely, when blah has been added, but not committed, > > > > svn diff -rBASE blah > > > > gives a diff instead of an error (indeed an error is expected because > > b...@base doesn't exist, as this can been seen with "svn cat blah"). > >

Re: svn diff - Is this behaviour expected?

On 2010-08-15 00:01:29 +0200, Vincent Lefevre wrote: > Conversely, when blah has been added, but not committed, > > svn diff -rBASE blah > > gives a diff instead of an error (indeed an error is expected because > b...@base doesn't exist, as this can been seen with "

Re: svn diff - Is this behaviour expected?

On 2010-08-14 04:05:17 +0100, chr...@lavabit.com wrote: > Is this expected/desired? Should I create a new issue? (I couldn't > find anything similar.) > Is there a consistent (backwards & forwards compatible) syntax I can > use? I have the same problems at least on the cases without -r. This doe

repository corruption by "svnadmin upgrade"

I've posted messages about the following problem in the users list, but here's other information. After a "svnadmin upgrade" with svn version 1.5.1 (r32289), which terminated without any error, and svn-populate-node-origins-index, the repository got corrupted: /svnroot/mpfr/db/format now contains

Re: description of Peg Revision Algorithm is incomplete

On 2010-03-30 21:36:27 +0200, Stefan Sperling wrote: > Maybe we could some day extend peg revision syntax so that every > component of a path can be pegged? > > So what Vincent wants would be something like this: > > $ svn cat @50/some/file.c I almost proposed this, but the syntax would no

Re: description of Peg Revision Algorithm is incomplete

On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote: > Interactions in the working copy with the path some/file.c only make sense > if there is actually such a path in the working copy. If some/file.c is > deleted in r51, then either it isn't in your working copy (because you've > updated past r

Re: description of Peg Revision Algorithm is incomplete

On 2010-03-30 09:31:27 -0400, C. Michael Pilato wrote: > Nobody should be trying to run 'svn cat some/fil...@50' if what they mean is > "follow the history of some/file.c back to r50 and cat the contents there". > That's just not the correct syntax for invoking the algorithm, and no > amount of wi

Re: description of Peg Revision Algorithm is incomplete

On 2010-03-29 12:36:11 -0400, C. Michael Pilato wrote: > I was about to post that one place where there might be a lack of > documentation is not so much in understanding what the peg revision means, > but in understanding the "working copy path" -> "peg path" translation. The > peg path algorithm

Re: description of Peg Revision Algorithm is incomplete

On 2010-03-29 17:07:36 +0100, Julian Foad wrote: > I expect Vincent is asking how 'svn' interprets 'svn info > some/deep/fil...@50'. It does accept such target specifiers (at least > for some commands) but it's not clear how it does or should interpret > them. Yes, this is what I meant. On 2010-

description of Peg Revision Algorithm is incomplete

Hi, The description of the Peg Revision Algorithm on http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.pegrevs is incomplete. It doesn't say how is identified when it is relative to a working copy. This is particularly important when the directory in question has been renamed/mo

<    1   2