| 1 |
Kevin F. Quinn wrote: |
| 2 |
> On Sat, 21 Apr 2007 12:00:55 +0200 |
| 3 |
> Thilo Bangert <bangert@g.o> wrote: |
| 4 |
> |
| 5 |
>>> I do the same. The '$Header: $' tells me which version of a file in |
| 6 |
>>> the CVS tree I last synced to in my overlay, then I can just do a |
| 7 |
>>> cvs diff on the tree to get a patch of differences since then. Very |
| 8 |
>>> useful. |
| 9 |
>> right - but this functionality would not go away - it would just have |
| 10 |
>> to be implemented differently. a potential move to git would make |
| 11 |
>> this much more easy, if i am not mistaken. |
| 12 |
> |
| 13 |
> By "implemented differently" you mean "by adding extra steps and data |
| 14 |
> to the synchronisation process". Currently, I compare the Header field |
| 15 |
> in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, |
| 16 |
> and use the difference to drive the 'cvs diff' command to get a patch. |
| 17 |
> |
| 18 |
> Removing the header would mean I'd have to record the origin version |
| 19 |
> somewhere, and keep that up-to-date whenever the file is |
| 20 |
> re-synchronised. |
| 21 |
> |
| 22 |
> Having said that, it only works for me because my overlay is in SVN and |
| 23 |
> and is not configured to process CVS header keywords. |
| 24 |
> |
| 25 |
> However I can honestly say that in my experience, the file revision |
| 26 |
> identification is _always_ recorded in the file - I've never yet seen |
| 27 |
> an SCM used in practice that didn't have that information. The reason |
| 28 |
> people put that information in, is so that when the file is taken out |
| 29 |
> of the context of the SCM repository, it's still clear where it came |
| 30 |
> from. This is precisely how I'm using it. |
| 31 |
|
| 32 |
GIT records the content of files in 'blobs', so the only keyword var |
| 33 |
that makes sense in a file is $blobId$, which would expand to a SHA1 |
| 34 |
checksum of the file. The design here is to re-use blob's when the SHA1 |
| 35 |
matches to save on computation. Since $blobID$ only really changes when |
| 36 |
the content changes (ie they are tied together) there is no 'loss' in |
| 37 |
having a $blobId$. |
| 38 |
|
| 39 |
If you put something like author in there, the author may change, or the |
| 40 |
author may be the same for every commit to a particular file. Binding |
| 41 |
the author means you change the checksum of the file every time the |
| 42 |
author changes, so if I commit rev1 and I commit rev2 and then you |
| 43 |
revert the file back to rev1, if we have $header$, the SCM wouldn't be |
| 44 |
able to re-use the blob from rev1 because my name is in the blob, |
| 45 |
instead of yours. I'll spare you the details[1]. |
| 46 |
|
| 47 |
PS: We aren't switching version control systems as far as I'm aware. |
| 48 |
Robin is just doing research into moving to git. The whole point of his |
| 49 |
inquiry is 'is anyone using $header in a manner than cannot be ported to |
| 50 |
using $blobid$'. |
| 51 |
|
| 52 |
[1] http://thread.gmane.org/gmane.comp.version-control.git/44750 |
| 53 |
-- |
| 54 |
gentoo-dev@g.o mailing list |
Archives