| 1 |
On Sat, 21 Apr 2007 12:00:55 +0200 |
| 2 |
Thilo Bangert <bangert@g.o> wrote: |
| 3 |
|
| 4 |
> > I do the same. The '$Header: $' tells me which version of a file in |
| 5 |
> > the CVS tree I last synced to in my overlay, then I can just do a |
| 6 |
> > cvs diff on the tree to get a patch of differences since then. Very |
| 7 |
> > useful. |
| 8 |
> |
| 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 |
-- |
| 33 |
Kevin F. Quinn |
Archives