Again, I may be wrong, but...
I think we may be fundamentally confusing subversion's tree versioning (full
repository versions) with CVS-style individual *file* revisions.
Files don't have revisions - they have a particular state marked in time by
a particular repo revision. A file (or directory) may not change a bit
between the version 110 and 111, or between 110 and 453, yet it will still
show as version 453 because that's the file as it was when the *repo* bumped
to revision 453.
Unless I missed something (not the first time) I believe the behavior you're
seeing is just the natural way a version-tree system like Subversion is
designed to behave. It's a fundamental difference in thinking from systems
using individual file-based revision numbers.
It's not "the file is version 111 which differed from 110", it's "the file
as it was in repo version 111". The file may or may not have changed between
repo revision 110 and 111.
-----Original Message-----
From: p.herth@gmail.com [mailto:p.herth@gmail.com] On Behalf Of Peter Herth
Sent: Friday, June 01, 2007 7:35 AM
To: Shawn Talbert
Cc: Hari Kodungallur; users@subversion.tigris.org
Subject: Re: svn status issues when deleting a file
On 6/1/07, Shawn Talbert <stalbert@exploreconsulting.com> wrote:
> I may be wrong here, but I was under the impression that subversion's
> "directory versioning" considers just the directory itself (e.g. changing
> properties, adding/delete/renames) not to the directory *contents*?
>
The fact that subversion *does* assign a new version number to the
directory after the file deletion shows that subversion considers it a
change of the directory object. But unfortunately, the new version is
shown only after an update, as my example showed.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 1 17:23:22 2007