On 2007-03-21 13:47:29 -0500, Peter Samuelson wrote:
>
> [Vincent Lefevre]
> > Note that upstream doesn't want to fix the bug:
> >
> > http://svn.haxx.se/dev/archive-2007-03/0734.shtml
>
> More to the point, they've chosen a different fix, which is to also
> store and look at file size.
This
[Vincent Lefevre]
> Note that upstream doesn't want to fix the bug:
>
> http://svn.haxx.se/dev/archive-2007-03/0734.shtml
More to the point, they've chosen a different fix, which is to also
store and look at file size.
See #376124 for the recode maintainer's reaction - he doesn't seem to
unde
Note that upstream doesn't want to fix the bug:
http://svn.haxx.se/dev/archive-2007-03/0734.shtml
The reason is that they don't want to support tools that don't modify
the mtime value[1], seen as "dangerous and broken". So, there should
a patch on Debian's side, e.g. using ctime instead of (or
[François Pinard]
> I quite object to the principle that Subversion limitations may be
> turned into Recode bugs, and even go as far as being considered
> "grave".
The severity 'grave' may or may not be correct - when redirecting the
bug report to 'recode', I simply left it at the severity it was
I think the problem can also be visible with a script that does a
commit on a file with a keyword and modifies the file just after,
at least on fast machines. Indeed, since there is a keyword, the
file will be modified by svn just after the commit, and the script
may modify the file in the same sec
On 2006-07-01 20:23:09 -0500, Peter Samuelson wrote:
> [Vincent Lefevre]
> > And again, this problem is not specific to "mv". MUAs also set the
> > mtime to the old value when modifying an mbox file (for some
> > technical reason).
>
> I never quite understood the timestamp manipulations of mbox f
[Vincent Lefevre]
> The Subversion book says concerning changes in the working copy:
>
> To make file changes, use your text editor, word processor, graphics
> program, or whatever tool you would normally use.
>
> And "mv" is one of these tools.
That is a point.
> And again, this problem
On 2006-07-01 16:10:58 -0500, Peter Samuelson wrote:
> [Vincent Lefevre]
> > mv *must be* supported. It's a Unix command and the user is allowed to
> > use it.
>
> That's a poor argument - the user is allowed to use 'rm -fr .svn' and
> subversion can't recover from that state. It's equally plausi
[Vincent Lefevre]
> mv *must be* supported. It's a Unix command and the user is allowed to
> use it.
That's a poor argument - the user is allowed to use 'rm -fr .svn' and
subversion can't recover from that state. It's equally plausible, in
fact, that a user who doesn't know how to use svn will d
On 2006-06-30 20:33:08 -0500, Peter Samuelson wrote:
> mv within a subversion working copy isn't supported anyway; what you do
> instead is 'svn rename' or 'svn copy'.
mv *must be* supported. It's a Unix command and the user is allowed to
use it. I'm not saying that I want that same behavior as "s
severity 376103 normal
thanks
[Vincent Lefevre]
> > I'm copying this bug to recode. In my opinion, 'svn' and 'make'
> > should be entitled to assume that the user has been honest about
> > modifications of her own files.
>
> I agree about make, but concerning svn, one can't rely on that.
I'm s
severity 376103 grave
thanks
On 2006-06-30 06:29:29 -0500, Peter Samuelson wrote:
> I find it hard to put into words just how broken I think this is, and I
> hope it's obvious enough that I don't have to. You just _don't_ modify
> files on a Unix filesystem and then hide the fact that you did so,
clone 376103 -1
retitle -1 recode: bad default: hides file modifications by restoring mtimes
reassign -1 recode
severity 376103 normal
thanks
[Vincent Lefevre]
> The "recode" utility does not update the timestamp (I assume this is
> a feature).
Yeah, well ... I don't know whose brilliant idea it
Package: subversion
Version: 1.3.2-3
Severity: grave
Justification: causes non-serious data loss
The "recode" utility does not update the timestamp (I assume this is a
feature). When a file is modified by recode, the commands "svn status"
and "svn diff" don't report any change, and "svn revert " d
14 matches
Mail list logo
