| 1 |
On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: |
| 2 |
> > Why do you need to identify the changes? Considering that the checksum |
| 3 |
> > changes as well, is detecting change not sufficient? (or asking the |
| 4 |
> > VCS for what files have changed since your last check time). |
| 5 |
> I am writing a tool that creates deb (as in Debian package format) based |
| 6 |
> distributions from gentoo packages and that tool encodes the CVS |
| 7 |
> revision as part of "debian revision" of the packages. So I need this |
| 8 |
> part to be chronologically ordered, as opposed to have only the |
| 9 |
> knowledge of whenever the file has changed or not. |
| 10 |
I'd call that critically dangerous in missing some changes. |
| 11 |
If I have a file in $FILESDIR, and change it, but it has the same name, |
| 12 |
there is no commit to the ebuild, and your .debs won't pick up changes |
| 13 |
at all. This is usually for cases with compile fixes that don't need |
| 14 |
revision bumps at all, but sometimes there are also changes to scripts. |
| 15 |
|
| 16 |
If you're making binary package .debs, I gather that you are grabbing |
| 17 |
the (pre|post)(inst|rm) and setup blocks for inclusion? |
| 18 |
|
| 19 |
That is an interesting use case, and would that would present a problem |
| 20 |
with any VCS migration. |
| 21 |
- Under SVN, you'd only have the global revision, which might not |
| 22 |
uniquely identify the file. |
| 23 |
- Bzr doesn't support keyword expansion in any released version. There |
| 24 |
are/were plans for it in 1.7, but I haven't seen anything since the |
| 25 |
first prototype. |
| 26 |
- Hg supports it with an extension: |
| 27 |
http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension |
| 28 |
But has warnings about why it sucks |
| 29 |
http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan |
| 30 |
See the 'keyword update intervals' item (mainly having to touch every |
| 31 |
file in the repo sometimes). |
| 32 |
- Git supports only the $Id$ keyword, and expands it to the SHA1 of the |
| 33 |
file, which ends up being a duplicate of the information we have in |
| 34 |
the Manifest. |
| 35 |
|
| 36 |
-- |
| 37 |
Robin Hugh Johnson |
| 38 |
Gentoo Linux Developer & Infra Guy |
| 39 |
E-Mail : robbat2@g.o |
| 40 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives