On 6/1/07, Shawn Talbert <stalbert@exploreconsulting.com> wrote:
> 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.
While I am aware of the repository revisions, svn explicitly keeps
track of the last version (of the repository) any file or directory
was changed in, and prints it as the second number in svn status. This
number increases only when the content of a file or directory was
committed. My only problem is, that while this number is changed in
status upon a commit of a file, for the case of the deletion from a
directory this number is changed as well, but not shown in status
until you run svn up. Alternatively, I would be equally happy if the
directory is shown as out-of-date as it requires an update to get the
new version number (as the last committed version) shown.
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:34:58 2007