Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). ~mcummings -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgptWlLTib1Xl.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, Apr 20, 2007 at 02:22:20PM -0700, Robin H. Johnson wrote: Counter-case for this is that the ChangeLog should also be updated (but some developers aren't very good about that...), and that can be checked too. Only applicable if what's being updated is an ebuild - there's also eclasses, everything under profiles, etc. -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgp5YukJXJy7Q.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
Am Sonntag, 22. April 2007 schrieb Michael Cummings: On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). This can be done using checksum like SHA1 much better, as people can edit their ebuilds/eclasses/profiles and forget/lie about it, and still have the same $Headers$ line. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sun, 22 Apr 2007 17:46:18 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Am Sonntag, 22. April 2007 schrieb Michael Cummings: On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). This can be done using checksum like SHA1 much better, as people can edit their ebuilds/eclasses/profiles and forget/lie about it, and still have the same $Headers$ line. In practice I find it's rare that a user has been hacking around in the eclasses. All the SHA1 tells you is that it's not the most recent, but it's not easy to determine from the SHA1 exactly which version they do have (so it's not enough to determine what's different). Having said that, the most accurate way to find out what they have is to get them to attach the eclass and diff it yourself. However relying on the SHA1 also means you can't just say things like, Check eclass blah is version 1.836 (look at the $Header line at the top of the file). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
Am Sonntag, 22. April 2007 schrieb Kevin F. Quinn: On Sun, 22 Apr 2007 17:46:18 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Am Sonntag, 22. April 2007 schrieb Michael Cummings: On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. FWIW, I've used the $Header $ to determine if a person is looking at the latest greatest or needs to synch up first (in particular when I was dealing with an eclass bug). Very useful when dealing with bugs and you need to confirm that the user is completely synch'd up and looking at a current tree or not (because just asking when the last time they synch'd doesn't help). This can be done using checksum like SHA1 much better, as people can edit their ebuilds/eclasses/profiles and forget/lie about it, and still have the same $Headers$ line. In practice I find it's rare that a user has been hacking around in the eclasses. All the SHA1 tells you is that it's not the most recent, but it's not easy to determine from the SHA1 exactly which version they do have (so it's not enough to determine what's different). Having said that, the most accurate way to find out what they have is to get them to attach the eclass and diff it yourself. However relying on the SHA1 also means you can't just say things like, Check eclass blah is version 1.836 (look at the $Header line at the top of the file). In the case of GIT you can just use 'git diff SHA1SUM' to see what has changed or 'git log SHA1SUM..HEAD' to show a list of revisions in between. So _if_ we changed to git, this would be no problem as long as every user has sha1sum installed [which is part of coreutils]. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 20 Apr 2007 14:30:54 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
So I'd be in favour of getting rid of them, if we make sure that everybody always commits to the ChangeLog (Make it a repoman failure). Side benefit of removing the need to double-commit from the hashes changing. i have never understood why repoman doesn't automatically put the commit message into the ChangeLog (share your use case!) taking this one more step ahead, the ChangeLog could perhaps be made a virtual file, which on demand is extracted from VCS metadata... now _that_ would save some bandwidth and space (no numbers, sorry). i am all for the removal of $Header:$, btw. the current double commits simply suck! regards Thilo pgpFGtCBHRfL3.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. right - but this functionality would not go away - it would just have to be implemented differently. a potential move to git would make this much more easy, if i am not mistaken. kind regards Thilo pgpva6EUHQ2Yb.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
So to sum up this thread: It seems that: a) we are moving to GIT which doesn't cope with $Header: $ stuff b) we want to avoid the double commit caused by $Header: $ For a) I would prefer then to remove the $Header: $ stuff until GIT is really about to be used. In a GIT world things will change completely anyway (if it works at all). Then for b) I like to suggest to ask the portage team to simply skip the $Header: $ part(s) when calculating the digests, and shove that change in at the same time manifest1 is obsoleted and migrated into the tree (removal of digest-* files). On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, 21 Apr 2007 12:00:55 +0200 Thilo Bangert [EMAIL PROTECTED] wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. right - but this functionality would not go away - it would just have to be implemented differently. a potential move to git would make this much more easy, if i am not mistaken. By implemented differently you mean by adding extra steps and data to the synchronisation process. Currently, I compare the Header field in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, and use the difference to drive the 'cvs diff' command to get a patch. Removing the header would mean I'd have to record the origin version somewhere, and keep that up-to-date whenever the file is re-synchronised. Having said that, it only works for me because my overlay is in SVN and and is not configured to process CVS header keywords. However I can honestly say that in my experience, the file revision identification is _always_ recorded in the file - I've never yet seen an SCM used in practice that didn't have that information. The reason people put that information in, is so that when the file is taken out of the context of the SCM repository, it's still clear where it came from. This is precisely how I'm using it. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabian Groffen wrote: So to sum up this thread: It seems that: a) we are moving to GIT which doesn't cope with $Header: $ stuff we are _not_ moving to any different scm anytime soon. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo Council Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iQCVAwUBRipAq4BrouQZ9K4FAQLsTQP/ejvTR/mrscrbOgDsdG1mNZUcpR+0aaru DLasHWjixW3Cs2BJccuP4XhSXeZJ9zd6cbAUJXlmNBUoimnxKT3/Nz/NboiOMJzJ 6B0Kuqb+EfaId5LkZpAUNwFeBCd/nTjFbnZu5pKRGrqbNL0jetaAkG4ZkFWy12P+ dRQUDeUB0v4= =gJCb -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Kevin F. Quinn wrote: On Sat, 21 Apr 2007 12:00:55 +0200 Thilo Bangert [EMAIL PROTECTED] wrote: I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. right - but this functionality would not go away - it would just have to be implemented differently. a potential move to git would make this much more easy, if i am not mistaken. By implemented differently you mean by adding extra steps and data to the synchronisation process. Currently, I compare the Header field in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, and use the difference to drive the 'cvs diff' command to get a patch. Removing the header would mean I'd have to record the origin version somewhere, and keep that up-to-date whenever the file is re-synchronised. Having said that, it only works for me because my overlay is in SVN and and is not configured to process CVS header keywords. However I can honestly say that in my experience, the file revision identification is _always_ recorded in the file - I've never yet seen an SCM used in practice that didn't have that information. The reason people put that information in, is so that when the file is taken out of the context of the SCM repository, it's still clear where it came from. This is precisely how I'm using it. GIT records the content of files in 'blobs', so the only keyword var that makes sense in a file is $blobId$, which would expand to a SHA1 checksum of the file. The design here is to re-use blob's when the SHA1 matches to save on computation. Since $blobID$ only really changes when the content changes (ie they are tied together) there is no 'loss' in having a $blobId$. If you put something like author in there, the author may change, or the author may be the same for every commit to a particular file. Binding the author means you change the checksum of the file every time the author changes, so if I commit rev1 and I commit rev2 and then you revert the file back to rev1, if we have $header$, the SCM wouldn't be able to re-use the blob from rev1 because my name is in the blob, instead of yours. I'll spare you the details[1]. PS: We aren't switching version control systems as far as I'm aware. Robin is just doing research into moving to git. The whole point of his inquiry is 'is anyone using $header in a manner than cannot be ported to using $blobid$'. [1] http://thread.gmane.org/gmane.comp.version-control.git/44750 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Thilo Bangert wrote: So I'd be in favour of getting rid of them, if we make sure that everybody always commits to the ChangeLog (Make it a repoman failure). Side benefit of removing the need to double-commit from the hashes changing. i have never understood why repoman doesn't automatically put the commit message into the ChangeLog (share your use case!) Yeah I would like at least a switch that would call echangelog first and then do its stuff, sunrise-commit which I use for overlays has -c for this. Hm well I can make myself a wrapper but if it was already there, it would be better :) taking this one more step ahead, the ChangeLog could perhaps be made a virtual file, which on demand is extracted from VCS metadata... now _that_ would save some bandwidth and space (no numbers, sorry). Interesting idea, if that's possible with CVS... but I don't see how it saves space and bandwith for rsync users. i am all for the removal of $Header:$, btw. the current double commits simply suck! I would leave it as long as we use CVS, for the reasons others already said (syncing changes to overlays which I myself used to do). But if we move to some other VCS, it would destroy the beauty of atomic commits... -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, Apr 21, 2007 at 10:54:15AM -0700, Alec Warner wrote: PS: We aren't switching version control systems as far as I'm aware. Robin is just doing research into moving to git. The whole point of his inquiry is 'is anyone using $header in a manner than cannot be ported to using $blobid$'. [1] http://thread.gmane.org/gmane.comp.version-control.git/44750 That thread was a followup to this previous thread: http://thread.gmane.org/gmane.comp.version-control.git/44298 Wherein I discussed what Gentoo would need out of Git that wasn't yet fully polished in Git (as followup research to see if Gentoo _were_ switching to Git, what would happen). The second thread came about because somebody else posted a partial prototype, that Linus Torvalds then dissected for why it wouldn't work with Git. Torvalds notes that if you are taking the file out of the repository, it should be done with 'git export' adding revisions during that process, but this means that the developers and users get different content :-(. As a useful side, our Manifest files already contain the SHA1 of the ebuilds, and those are in fact the Git BlobIds, so we do have them recorded there, but the Manifest gets regenerated, so it's easy to lose them. Linus's response on the style of problem you have in copying files over to your overlay, is that your overlay should be a Git branch of the original tree. -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpm0YOdEL6mS.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, Apr 21, 2007 at 12:40:42PM +0200, Fabian Groffen wrote: a) we are moving to GIT which doesn't cope with $Header: $ stuff Please drop this notion. My work on the Git mailing lists has strictly been: - IFF Gentoo WANTED to switched to Git, how would Git have to change. This was my posting to the Git mailing list: http://thread.gmane.org/gmane.comp.version-control.git/44298/focus=44473 Summarizing from that list: #1 History slicing - In Git already, some minor bugs I identified #2 Subtree slicing - External patchset to Git, WIP #3 ACL support - Patch was posted to the Git ML yesterday, needs some Gentoo-specific polishing. #4 Keywords - see the massive threads on the Git ML that were spawned These also intersect with my own needs for Git for work projects, so I can justify some of my work time for doing some Git development. That said, from a VCS management point of view, and understanding the results of Antarus's GSoC2006 work [1], SVN wasn't really suitable on the server or client side (massive disk hog compared to CVS amongst other things). The best option on the management side of things, is still to stick with CVS at the moment. [1] http://www.gentoo.org/proj/en/infrastructure/cvs-migration.xml but beware that the results themselves are from August 2006, and have changed radically for Git - SVN may have changed radically as well, I don't follow SVN enough to know. -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpoS3BWiruA0.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, Apr 20, 2007 at 08:22:42AM -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -mike I don't see a reason to keep it... so lets kill it. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpMM3rYE1Bit.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Friday 20 of April 2007 14:22:42 Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong ++ and it's a PITA for git(we should eventually switch to something sane, right?) and our commit system which must regenerate the Manifest only after commit so let's kill it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 20 Apr 2007 14:52:46 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 20-04-2007 15:45:00 +0300, Petteri Räty wrote: I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. Is the info you need in CVS/ ? That requires: a) an up-to-date CVS tree checkout b) a CVS tree (not a regular rsynced one) c) parsing of the CVS/Entries file So in principle, yes I think it can be done using the CVS directory, but I prefer not to. +1 on this one. I am writing some script to automate package building and use the Header field to detect CVS revision changes. I know I could do it with hash values, but then it would be harder to have builds from different revisions of the same ebuild file time ordered. Best, Yuri. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -mike brains brains. errr I mean... ++ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 2007-04-20 at 08:22 -0400, Mike Frysinger wrote: does anyone actually find this useful ? yes quite useful. i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs That it does also if the diff is of course in the first few lines. - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -mike -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On 20-04-2007 09:11:10 -0500, Yuri Vasilevski wrote: On Fri, 20 Apr 2007 14:52:46 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: Is the info you need in CVS/ ? That requires: a) an up-to-date CVS tree checkout b) a CVS tree (not a regular rsynced one) c) parsing of the CVS/Entries file So in principle, yes I think it can be done using the CVS directory, but I prefer not to. +1 on this one. I am writing some script to automate package building and use the Header field to detect CVS revision changes. I know I could do it with hash values, but then it would be harder to have builds from different revisions of the same ebuild file time ordered. I thought about it some longer, and it's even nastier than just having to get the value in a different way, because you also have to keep the value in the file in your local version. This either means also storing the CVS directory (in SVN, funny :) ) or devoting the first line of every file for it... Side question: is it a problem that you cannot easily see which (CVS) version of an ebuild is in the rsync tree you/user have/has? I guess that's what the $Header: $ thing is actually for. I can't recall any occasion myself that I used it to track an issue with it though. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Fabian Groffen kirjoitti: On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. Is the info you need in CVS/ ? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] $Header:$ and ebuilds
I thought about it some longer, and it's even nastier than just having to get the value in a different way, because you also have to keep the value in the file in your local version. This either means also storing the CVS directory (in SVN, funny :) ) or devoting the first line of every file for it... You can make it into svn versioned property ;-) Love, H -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Alle venerdì 20 aprile 2007, Fabian Groffen ha scritto: On 20-04-2007 15:45:00 +0300, Petteri Räty wrote: I use it to make deltas of changes made in the tree, and apply those deltas on the overlay I'm using. Without $Header: $ there I have no way to actually see which version I'm dealing with, so which revisions to retrieve for differences. For that reason, I prefer as much files as possible in the tree to have a $Header: $ somewhere, so I can easily sync, keeping my local changes. Is the info you need in CVS/ ? That requires: a) an up-to-date CVS tree checkout b) a CVS tree (not a regular rsynced one) c) parsing of the CVS/Entries file So in principle, yes I think it can be done using the CVS directory, but I prefer not to. +1 Header is useful to know which ebuild have the user -- Timothy `Drizzt` Redaelli - http://dev.gentoo.org/~drizzt/ FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
