On 6/1/07 12:09 PM, "Peter Herth" <herth@peter-herth.de> wrote:
> On 6/1/07, Matt Sickler <crazyfordynamite@gmail.com> wrote:
>> Okay, so the number doesnt change when expected. Is it really a problem?
>
> This is a real problem, as I try to find out programmatically, whether
> my workarea changed or not (with respect to the latest tag). The
> simplest way is to compare the commit versions of the file with the
> repository version of the tag. The file deletion is the only case
> where this fails. Of course I can come up with a workaround, but the
> more I investigated this, the more it seemed as a bug in status, so I
> thought it would be a worthwhile contribution to report it - yet I
> decided to run the idea past this list first before creating a bug
> report.
I think it's a separate issue, but this isn't the first time I've seen bugs
in the working copy relating to committed deletions. Check out this one:
http://subversion.tigris.org/issues/show_bug.cgi?id=2763
In this situation, when you commit the deletion of a directory, the metadata
for the parent of the deleted directory does not get properly updated. Then
when you try and create a tag from the working copy with 'svn cp', it gives
you an error saying that the data is missing. This is really annoying as
the only way to work around it is to do an update of the parent directory.
This isn't necessarily a viable solution in my case, since the creation of a
tag didn't necessarily want the update to occur.
>
>> Does it somehow keep you from using SVN? If so, work up a patch and
>> submit it to the svn devs. Otherwise, just ignore it.
>
> As said before, it does not keep me from using SVN, I thought
> discussing my observation may be the first step to solving it.
>
>> So what if a
>> directory doesnt up its version number when a file within it changes?
Getting the last-committed revision is the only way to really determine if
two revisions are different aside from actually doing a diff. A user
doesn't want to see that two separate tags were created from revisions 3 and
4 of the same file only to find out that those were really the same
committed revision. They really want to see a consistent revision number
when no changes have been committed to a file. It would really be nice if
you could do the same with the directory.
>
> Then the file has its number changed, and that is fully fine and sufficient.
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 2 03:24:36 2007