"RCS $Revision"

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2010 6:40 AM, Max Bowsher wrote:
>> On 11/22/2010 2:53 PM, Michael Andronov wrote:
>>> I'm wondering if bzr has a feature similar to "RCS $Revision"?
> 
> On 22/11/10 21:54, John Arbash Meinel wrote:
> ...
>> SVN is a little better in that it strips the field for commit and merge,
>> but has the problem that what you commit isn't what you checkout. And
>> has had quite a few bugs wrt commit at rev 10, checout at rev 12, what
>> should be in that tag?
> 
> What sort of bug are you talking about? SVN's keyword handling is fairly
> simple, conceptually, if perhaps not always what people think.

I don't know the specifics, but I've gleaned a bit from talking with the
people who implement converters. One of the problems that Launchpad's
import system ran into was that doing:

 svn co -r 10
 bzr commit
 svn update -r 11
 bzr commit

 svn co -r 11

The final 'co -r 11' wouldn't match the commit from 'up -r 11'. I
believe the issue was $Revision$ type flags. The issue was that it was
giving the *tree* revno, and not the *last modified* revno.

So in the above, say 'foo' was modified in r10.
 svn co -r10; head foo == "$Revision: 10$
 svn co -r11; head foo == "$Revision: 11$

versus
 svn co -r10; svn up -11; head foo == "$Revision: 10$"

The reason is that 'update' would only modify files that were actually
updated, but 'co' would set all of the $Revision$ fields to the revno
that you were checking out.

Some of this is because svn was stripping the content. So it didn't
immediately know *when* the file was last modified, so it just shoved
the current revno in there.


Things might have changed, but I'm pretty sure that was the case when
people were working on it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzr0uUACgkQJdeBCYSNAANLAACfdxNmV1kSMXRooelmOLrVOHMh
LqgAoKlKo7HaDSKx7jZmWTFToEYEGHSg
=ACa0
-----END PGP SIGNATURE-----