[gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

Hi folks,

I'm doing some research on our usages of the $Header$ keyword in our
main CVS repo.

The primary use-case that has been publicly stated before was for users
to be able to identify to developers what version of a given ebuild they
were using.

Q: How much have you utilized the primary use case?

Q: Are there any other use-cases you have and actively use?

For evaluating existing uses of the primary case, I took a glance at
Bugzilla. There are 624 bugs total that contain a $Header$ with an
existing Gentoo path. At least 143 of those are for new packages or
version bumps (they copied existing ebuilds).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Yuri Vasilevski]

Hi,

On Tue, 26 Aug 2008 13:40:36 -0700
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> I'm doing some research on our usages of the $Header$ keyword in our
> main CVS repo.
> 
> Q: Are there any other use-cases you have and actively use?

I use the revision present in the header to identify changes in
ebuild files that didn't needed a revision dump.

Kindest regards,
Yuri.

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote:
> > I'm doing some research on our usages of the $Header$ keyword in our
> > main CVS repo.
> > 
> > Q: Are there any other use-cases you have and actively use?
> I use the revision present in the header to identify changes in
> ebuild files that didn't needed a revision dump.
Err, what do you mean by revision dump?

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Yuri Vasilevski]

On Tue, 26 Aug 2008 13:54:21 -0700
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote:
> > > I'm doing some research on our usages of the $Header$ keyword in
> > > our main CVS repo.
> > > 
> > > Q: Are there any other use-cases you have and actively use?
> > I use the revision present in the header to identify changes in
> > ebuild files that didn't needed a revision dump.
> Err, what do you mean by revision dump?

revision dump is when foo-1.0-r4 becomes foo-1.0-r5.

But when foo-1.0-r4 is updated in-place, I use CVS revisions
(ej: 1.12 -> 1.13 in 2nd word in $ Header: ....)

Yuri.

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
> > Err, what do you mean by revision dump?
> revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
That's revision 'B'ump, not 'D'ump.

> But when foo-1.0-r4 is updated in-place, I use CVS revisions
> (ej: 1.12 -> 1.13 in 2nd word in $ Header: ....)
The $Header$ is filled out automatically by CVS, what are you using the
$Header$ string for?

Why do you need to identify the changes? Considering that the checksum
changes as well, is detecting change not sufficient? (or asking the VCS
for what files have changed since your last check time).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Yuri Vasilevski]

On Tue, 26 Aug 2008 14:45:25 -0700
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
> > > Err, what do you mean by revision dump?
> > revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
> That's revision 'B'ump, not 'D'ump.

Sorry, not native English speaker :$

> > But when foo-1.0-r4 is updated in-place, I use CVS revisions
> > (ej: 1.12 -> 1.13 in 2nd word in $ Header: ....)
> The $Header$ is filled out automatically by CVS, what are you using
> the $Header$ string for?
> 
> Why do you need to identify the changes? Considering that the checksum
> changes as well, is detecting change not sufficient? (or asking the
> VCS for what files have changed since your last check time).

I am writing a tool that creates deb (as in Debian package format) based
distributions from gentoo packages and that tool encodes the CVS
revision as part of "debian revision" of the packages. So I need this
part to be chronologically ordered, as opposed to have only the
knowledge of whenever the file has changed or not.

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
> > Why do you need to identify the changes? Considering that the checksum
> > changes as well, is detecting change not sufficient? (or asking the
> > VCS for what files have changed since your last check time).
> I am writing a tool that creates deb (as in Debian package format) based
> distributions from gentoo packages and that tool encodes the CVS
> revision as part of "debian revision" of the packages. So I need this
> part to be chronologically ordered, as opposed to have only the
> knowledge of whenever the file has changed or not.
I'd call that critically dangerous in missing some changes.
If I have a file in $FILESDIR, and change it, but it has the same name,
there is no commit to the ebuild, and your .debs won't pick up changes
at all. This is usually for cases with compile fixes that don't need
revision bumps at all, but sometimes there are also changes to scripts.

If you're making binary package .debs, I gather that you are grabbing
the (pre|post)(inst|rm) and setup blocks for inclusion?

That is an interesting use case, and would that would present a problem
with any VCS migration.
- Under SVN, you'd only have the global revision, which might not
  uniquely identify the file.
- Bzr doesn't support keyword expansion in any released version. There
  are/were plans for it in 1.7, but I haven't seen anything since the
  first prototype.
- Hg supports it with an extension:
  http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension
  But has warnings about why it sucks
  http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan
  See the 'keyword update intervals' item (mainly having to touch every
  file in the repo sometimes).
- Git supports only the $Id$ keyword, and expands it to the SHA1 of the
  file, which ends up being a duplicate of the information we have in
  the Manifest.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[René 'Necoro' Neumann]

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

Robin H. Johnson schrieb:
> On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
>> I am writing a tool that creates deb (as in Debian package format) based
>> distributions from gentoo packages and that tool encodes the CVS
>> revision as part of "debian revision" of the packages. So I need this
>> part to be chronologically ordered, as opposed to have only the
>> knowledge of whenever the file has changed or not.
> <snip>
> That is an interesting use case, and would that would present a problem
> with any VCS migration.

I don't see this problem ... I guess it is possible in all VCS to get
the information, which global revision touched a specific file last.

For example in bzr (these examples are conceived by me - so probably
there is an easier way):

bzr log -l1 --line $FILE | cut -f1 -d:

- --or: to have the unique rev-id instead of the branch-local rev-number--

bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' '


And hg,svn,git sure have similar abilities.

- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki0hZQACgkQ4UOg/zhYFuBTrgCeJ/2gfygwUvWCB5QOibsYz0mN
sGMAnRmqz/ChCg6zSAVrS4JljP1+DYRV
=g5fE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote:
> - --or: to have the unique rev-id instead of the branch-local rev-number--
> bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' '
IIRC, the revision-id is just like the Git $Id$, it's a hex string, not
an incremented counter like the revision number in CVS.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[René 'Necoro' Neumann]

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

Robin H. Johnson schrieb:
> On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote:
>> - --or: to have the unique rev-id instead of the branch-local rev-number--
>> bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' '
> IIRC, the revision-id is just like the Git $Id$, it's a hex string, not
> an incremented counter like the revision number in CVS.
> 

True ... it usually looks like
author@doma.in-20080821233630-v94w5lkebavkx9ti

Though, if one enforces certain policies using the "main branch" located
on the server like disallowing pushing and only allowing merges, one can
safely use the branch-revno (which is incremental). Only oddity are
revnos of merged branches (e.g. "193.1.10")

Another approach would be to use the unix-timestamp of the last change.
Though it is not a unique identifier per se, it should be sufficient here.
It should be queriable in all VCS. Though it might be, that it is not
possible using standard CLI and requires a plugin in some way (but I
bet, an easy one ;))

- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki0j3UACgkQ4UOg/zhYFuDZ+QCdGm7Sjew2+27KCUB06lWf8aLr
XBsAoIbJSke4xHyPiucYEmkuNVd9GPJ3
=jTaO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[René 'Necoro' Neumann]

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

René 'Necoro' Neumann schrieb:
> Only oddity are
> revnos of merged branches (e.g. "193.1.10")

Gnah - forget this issue.. from the main branch' viewpoint, the last
change is always in the merge revision, and not in a revision being
merged. So it is guaranteed to be an integer and not a combined thingy
as above ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki0kZMACgkQ4UOg/zhYFuDftQCfWHv+AvkqNJgZ/VwyIc1AV9WS
kJcAoIMmvsPv48GO4ixM4KE25TQtBHkm
=F3DM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Yuri Vasilevski]

On Tue, 26 Aug 2008 15:25:16 -0700
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
> > > Why do you need to identify the changes? Considering that the
> > > checksum changes as well, is detecting change not sufficient? (or
> > > asking the VCS for what files have changed since your last check
> > > time).
> > I am writing a tool that creates deb (as in Debian package format)
> > based distributions from gentoo packages and that tool encodes the
> > CVS revision as part of "debian revision" of the packages. So I
> > need this part to be chronologically ordered, as opposed to have
> > only the knowledge of whenever the file has changed or not.
> I'd call that critically dangerous in missing some changes.
> If I have a file in $FILESDIR, and change it, but it has the same
> name, there is no commit to the ebuild, and your .debs won't pick up
> changes at all. This is usually for cases with compile fixes that
> don't need revision bumps at all, but sometimes there are also
> changes to scripts.

Yes, I know that this will not protect me against changes in a file from
${FILESDIR} nor a change in a file in ${A}, but that was the best way I
could think of to make debian source packages (I create as well) as
reproducible as possible.

For the source packages I create a debian/rules[1] file that basically
calls ebuild foo.ebuild with the right options and to compile and then
install to a temporary directory and then call some debhelper scripts
to turn that directory into a proper .deb package. So from my
perspective the .ebuild file can be considered part of the debian/rules
files and because of that I really need to keep track of changes in it.

And for the rest of files, I bump ( :-D ) another revision counter with
each rebuild of the same debian source package version, so until I find
some better way to catch changes in any bit of the source (be it the
ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have
conflicts.

> If you're making binary package .debs, I gather that you are grabbing
> the (pre|post)(inst|rm) and setup blocks for inclusion?

Yes, I certainly do.

> That is an interesting use case, and would that would present a
> problem with any VCS migration.
> - Under SVN, you'd only have the global revision, which might not
>   uniquely identify the file.
> - Bzr doesn't support keyword expansion in any released version. There
>   are/were plans for it in 1.7, but I haven't seen anything since the
>   first prototype.
> - Hg supports it with an extension:
>   http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension
>   But has warnings about why it sucks
>   http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan
>   See the 'keyword update intervals' item (mainly having to touch
> every file in the repo sometimes).
> - Git supports only the $Id$ keyword, and expands it to the SHA1 of
> the file, which ends up being a duplicate of the information we have
> in the Manifest.

I am aware about this problem, and unless this is explicitly taken into
consideration on migration, I guess I'll have to keep a local database
of "order" of ebuilds as part of the metadata associated with each
distribution my tool creates.

[1] debian/rules files is a make file that provides the right targets
    for debian tools call it and generate deb binary packages. So it
    is kind of the equivalent of .ebuild scripts for debian.

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Raúl Porcel]

Robin H. Johnson wrote:
> On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
>>> Err, what do you mean by revision dump?
>> revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
> That's revision 'B'ump, not 'D'ump.
> 

bumb!!

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Fabian Groffen]

On 26-08-2008 15:41:07 -0500, Yuri Vasilevski wrote:
> On Tue, 26 Aug 2008 13:40:36 -0700
> "Robin H. Johnson" <robbat2@gentoo.org> wrote:
> 
> > I'm doing some research on our usages of the $Header$ keyword in our
> > main CVS repo.
> > 
> > Q: Are there any other use-cases you have and actively use?
> 
> I use the revision present in the header to identify changes in
> ebuild files that didn't needed a revision dump.

I do exactly the same (or, eupdate is doing that) to keep the Prefix
tree in sync with gentoo-x86.  That is, I use the CVS Header to
determine if a change has occurred, retrieve that diff, and apply the
patch on my Prefix version of the same file (ebuild, ChangeLog,
patch, eclass, ...).

For that reason I'd pretty much prefer to keep the CVS Header in place,
unless there is a very good reason to remove it.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote:
> For that reason I'd pretty much prefer to keep the CVS Header in place,
> unless there is a very good reason to remove it.
As I wrote in the other thread, my reason for asking is that it's one of
the things that doesn't have clear mapping in the Git world. As a side
benefit, getting rid of it also makes the double-commit mess go away.

For your use case, it should be possible to just ask Git for updates to
the given directory, and apply those to your own tree.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Fabian Groffen]

On 27-08-2008 10:28:57 -0700, Robin H. Johnson wrote:
> On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote:
> > For that reason I'd pretty much prefer to keep the CVS Header in place,
> > unless there is a very good reason to remove it.
> As I wrote in the other thread, my reason for asking is that it's one of
> the things that doesn't have clear mapping in the Git world. As a side
> benefit, getting rid of it also makes the double-commit mess go away.

For who is it a mess?  Not for repoman users, I suppose, and everyone
should be using it, right?  As the one who personally played with the
code in repoman that determines whether or not the "double commit" is
necessary, I think it's mostly a repoman internal problem.  The commit
script problems put aside.

> For your use case, it should be possible to just ask Git for updates to
> the given directory, and apply those to your own tree.

Another VCS is another story.  If we're switching, it would be nice if
the notion of overlays shadowing the main tree would be taken into
account.  Especially since I don't think Prefix will "merge" any time
soon, but we are plagued by the thing called "growth".


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Alec Warner]

On Wed, Aug 27, 2008 at 10:38 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 27-08-2008 10:28:57 -0700, Robin H. Johnson wrote:
>> On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote:
>> > For that reason I'd pretty much prefer to keep the CVS Header in place,
>> > unless there is a very good reason to remove it.
>> As I wrote in the other thread, my reason for asking is that it's one of
>> the things that doesn't have clear mapping in the Git world. As a side
>> benefit, getting rid of it also makes the double-commit mess go away.
>
> For who is it a mess?  Not for repoman users, I suppose, and everyone
> should be using it, right?  As the one who personally played with the
> code in repoman that determines whether or not the "double commit" is
> necessary, I think it's mostly a repoman internal problem.  The commit
> script problems put aside.

So you are saying we should do what?

precompute the CVS header and inject it into $header$ ourselves
take the checksums
generate the manifest
revert the $header$ change
then commit the ebuild and manifest at once

?

The only reason we have double commits right now is that the $header$
replacement is done by cvs at commit time so if we don't do two
commits the checksums all break due to the substitution..how is that
repoman's fault?

>
>> For your use case, it should be possible to just ask Git for updates to
>> the given directory, and apply those to your own tree.
>
> Another VCS is another story.  If we're switching, it would be nice if
> the notion of overlays shadowing the main tree would be taken into
> account.  Especially since I don't think Prefix will "merge" any time
> soon, but we are plagued by the thing called "growth".
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Wed, Aug 27, 2008 at 11:57:30AM -0700, Alec Warner wrote:
> So you are saying we should do what?
> 
> precompute the CVS header and inject it into $header$ ourselves
> take the checksums
> generate the manifest
> revert the $header$ change
> then commit the ebuild and manifest at once
> 
> The only reason we have double commits right now is that the $header$
> replacement is done by cvs at commit time so if we don't do two
> commits the checksums all break due to the substitution..how is that
> repoman's fault?
For those not using SSH ControlMaster, one of the side-effects of having
to do two separate commits is the SSH setup latency hitting twice.

I wouldn't call it repoman's fault like Fabian did, but the
double-commit is why I called it a mess. If we drop the $Header$ in any
file covered by a developer-generated Manifest, it becomes a single
commit with contents+Manifest :-).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Fabian Groffen]

On 27-08-2008 12:15:35 -0700, Robin H. Johnson wrote:
> For those not using SSH ControlMaster, one of the side-effects of having
> to do two separate commits is the SSH setup latency hitting twice.
> 
> I wouldn't call it repoman's fault like Fabian did, but the

Right.  I thought I suggested that "it" (the double-commit) is a mess
for repoman.  Not that it is repoman's fault.

> double-commit is why I called it a mess. If we drop the $Header$ in any
> file covered by a developer-generated Manifest, it becomes a single
> commit with contents+Manifest :-).

It seems that what you call "mess" means needing a double commit for a
single "repoman commit".  That to me isn't a mess, but a performance
issue, and as I indicated a possible point of corruption.  But we've
dealt long enough with the situation without problems to ignore that
point.

But to repeat:
- no I'm not against removing the $Header: $ stuff
- yes I'd even like to use another VCS which can make my life easer
- but, as long as we're on CVS, I'd prefer it when you'd keep my life
  sort of bearable
- so, keep the $Header: $ stuff for Prefix' sake (me) as long as
  we're using CVS


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Fabian Groffen]

On 27-08-2008 11:57:30 -0700, Alec Warner wrote:
> > For who is it a mess?  Not for repoman users, I suppose, and everyone
> > should be using it, right?  As the one who personally played with the
> > code in repoman that determines whether or not the "double commit" is
> > necessary, I think it's mostly a repoman internal problem.  The commit
> > script problems put aside.
> 
> So you are saying we should do what?
> 
> precompute the CVS header and inject it into $header$ ourselves
> take the checksums
> generate the manifest
> revert the $header$ change
> then commit the ebuild and manifest at once
> 
> ?
> 
> The only reason we have double commits right now is that the $header$
> replacement is done by cvs at commit time so if we don't do two
> commits the checksums all break due to the substitution..how is that
> repoman's fault?

It's not.  But I don't see the problem (apart from a "race condition"
with rsync generation) with the two commits either.

Incidently the $Header: $ "feature" just helps me a lot at the moment to
keep the Prefix tree up-to-date.  Hence, I'm against switching them off
or removing them as long as we use CVS for gentoo-x86.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On T, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote:
> The primary use-case that has been publicly stated before was for
> users
> to be able to identify to developers what version of a given ebuild they
> were using.
> 
> Q: How much have you utilized the primary use case?

Never. There has never been a reason to ask this from the user for me.
If the ebuild in question has changed without changing name, it has
always been obvious if it matters, and if the user has an old version if
it does (as then what the bug is about is what was just recently fixed
without revbump, typically build fixes).

> Q: Are there any other use-cases you have and actively use?

No.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Paul Varner]

On Tue, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote:
> Q: How much have you utilized the primary use case?
Not at all

> Q: Are there any other use-cases you have and actively use?
No

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Thilo Bangert]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

"Robin H. Johnson" <robbat2@gentoo.org> said:
> Hi folks,
>
> I'm doing some research on our usages of the $Header$ keyword in our
> main CVS repo.
>
> The primary use-case that has been publicly stated before was for users
> to be able to identify to developers what version of a given ebuild
> they were using.
>
> Q: How much have you utilized the primary use case?
>
> Q: Are there any other use-cases you have and actively use?
>
> For evaluating existing uses of the primary case, I took a glance at
> Bugzilla. There are 624 bugs total that contain a $Header$ with an
> existing Gentoo path. At least 143 of those are for new packages or
> version bumps (they copied existing ebuilds).


it appears we have decided to keep the $Header$ keyword in ebuilds for 
now. however, what about removing it from the ChangeLog?

kind regards
Thilo

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Wed, Oct 01, 2008 at 05:31:21PM +0200, Thilo Bangert wrote:
> > For evaluating existing uses of the primary case, I took a glance at
> > Bugzilla. There are 624 bugs total that contain a $Header$ with an
> > existing Gentoo path. At least 143 of those are for new packages or
> > version bumps (they copied existing ebuilds).
> it appears we have decided to keep the $Header$ keyword in ebuilds for 
> now. however, what about removing it from the ChangeLog?
The Debian pkg generation was the only use-case that didn't have an
immediate other solution. The Prefix guys need it while we are still on
CVS, but said it could vanish on the other side of the Git migration.

So probably just keep it everywhere until we switch VCS.

Random plug: Interested in VCS migration? Subscribe to the gentoo-scm
list.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]