GetBufferInfo for subversion does not return new version

[GoogleCodeExporter]

It seems that GetBufferInfo fails to see that a file has been updated.

As an example, a file openhex.py has been modified by the user openhex it
is now on revision 380. Here is the output of svn status from my computer
(not updated)

1251 nicoe@kinder ~/projets/pinte/www % svn status -vu openhex.py 
       *      379      376 nicoe        openhex.py
État par rapport à la révision    380

The '*' denotes the fact that the file has been updated, 379 denotes the
current revision on my computer and 376 denotes (wrongly ?) the last time
the  file has been updated (by me).

Maybe my subversion server is not reacting correctly but I think the
GetBufferInfo should also take into account the '*' in the returned output
to work around this bug.

Original issue reported on code.google.com by salocin....@gmail.com on 9 Mar 2008 at 6:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What do you expect GetBufferInfo to return in that instance?

Original comment by bob.hies...@gmail.com on 19 Mar 2008 at 6:54

[GoogleCodeExporter]

GetBufferInfo returns (379, 376) which is kind of pointless. (379, *) or even 
better
(but probably more difficult) (379, 380) so that I know the version I'm wroking 
on is
not the up-to-date one.

Original comment by salocin....@gmail.com on 24 Mar 2008 at 8:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The 380 in your example is meaningless; that's simply the repository's revision,
which may have been made in an entirely different branch and in any event may 
not
affect the current file.

I eventually plan on normalizing file states, so that I can consistently 
(across VCS)
report things like 'locally modified' or 'out of date'.  That state could then 
be
used to limit operations on the affected files (which is functionality I 
recently
removed due to it being too limited and not VCS-specific).

I agree that out-of-date information is useful.  I'll think about how adding 
that
relates to the previous file state information.

Thanks,

bob

Original comment by bob.hies...@gmail.com on 25 Mar 2008 at 1:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I confess I still don't understand what the '*' flag means.  I have a repo 
where the 
file is marked out-of-date, yet is later than the most recent change to that 
file.  I 
was also confused by the sample output; my SVN output doesn't contain the line 
corresponding to the '380' line number.  I'm guessing that it has to do with 
the 
transport protocol, or client/server setup, as a test repo I just created DOES 
show 
the extra line.

However, I updated this code anyway to handle newer SVN formats (9 characters 
for the 
flag instead of 8), so now I pass along the asterisk if found.  Look for it in 
the 
upcoming 1.99.40.

Original comment by bob.hies...@gmail.com on 30 Mar 2010 at 7:10

• Changed state: Fixed