{"thread":{"id":"1216","subject":"[PATCH] git-cvsimport-script: parse multidigit revisions","startedAt":"2005-07-12T21:35:32Z","lastAt":"2005-07-26T22:01:00Z","messageCount":11,"participants":["Sven Verdoolaege","Matthias Urlichs","Linus Torvalds","Ryan Anderson","Rene Scharfe","David Mansfield"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"6059","messageId":"20050712213531.GA10936@pc117b.liacs.nl","threadId":"1216","inReplyTo":null,"subject":"[PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Sven Verdoolaege","fromEmail":"skimo@liacs.nl","sentAt":"2005-07-12T21:35:32Z","receivedAt":"2005-07-12T21:35:32Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"git-cvsimport-script: parse multidigit revisions.\n\nPreviously, git-cvsimport-script would fail\non revisions with more than one digit.\n\nSigned-off-by: Sven Verdoolaege \n\n---\ncommit 7b5f7bcc470528beb4a0b6ef1c93ce634aaa0158\ntree db66d0759f97016bd123e2351aa0e77585e3177b\nparent e30e814dbfef7a6e89418863e5d7291a2d53b18f\nauthor Sven Verdoolaege Tue, 12 Jul 2005 22:36:57 +0200\ncommitter Sven Verdoolaege Tue, 12 Jul 2005 22:36:57 +0200\n\n git-cvsimport-script | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-cvsimport-script b/git-cvsimport-script\n--- a/git-cvsimport-script\n+++ b/git-cvsimport-script\n@@ -675,7 +675,7 @@ while() {\n \t\t$state = 9;\n \t} elsif($state == 8) {\n \t\t$logmsg .= \"$_\\n\";\n-\t} elsif($state == 9 and /^\\s+(\\S+):(INITIAL|\\d(?:\\.\\d+)+)->(\\d(?:\\.\\d+)+)\\s*$/) {\n+\t} elsif($state == 9 and /^\\s+(\\S+):(INITIAL|\\d+(?:\\.\\d+)+)->(\\d+(?:\\.\\d+)+)\\s*$/) {\n #\tVERSION:1.96->1.96.2.1\n \t\tmy $init = ($2 eq \"INITIAL\");\n \t\tmy $fn = $1;\n"},{"id":"6064","messageId":"20050713011818.GM9915@kiste.smurf.noris.de","threadId":"1216","inReplyTo":"20050712213531.GA10936@pc117b.liacs.nl","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-13T01:18:18Z","receivedAt":"2005-07-13T01:18:18Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nSven Verdoolaege:\n> Previously, git-cvsimport-script would fail\n> on revisions with more than one digit.\n> \nOuch. Thanks.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nWhen a guy says...\nGood idea.\n\tHe really means....\nIt'll never work. And I'll spend the rest of the day gloating.\n"},{"id":"6445","messageId":"Pine.LNX.4.58.0507251544300.6074@g5.osdl.org","threadId":"1216","inReplyTo":"20050713011818.GM9915@kiste.smurf.noris.de","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-25T23:00:49Z","receivedAt":"2005-07-25T23:00:49Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 13 Jul 2005, Matthias Urlichs wrote:\n> \n> Sven Verdoolaege:\n> > Previously, git-cvsimport-script would fail\n> > on revisions with more than one digit.\n> > \n> Ouch. Thanks.\n\nHmm.. I finally tried to import the bkcvs kernel tree into git, and while \nI'm cursing the slowness of CVS (I'm _hoping_ that part of the problem is \njust that CVS is especially slow with old versions of files, and that the \nimport will eventually start speeding up), there's definitely something \nwrong going on with new files in an archive...\n\nIn particular, they always end up being imported as zero-sized empty\nfiles, and will be filled in only later if that file is ever touched \nagain. In other words, the resulting git tree ends up being bogus.\n\nThe command line I used was\n\n\tgit cvsimport -d /home/torvalds/bkcvs -p --bkcvs linux-2.5\n\nand I wonder if it's the \"--bkcvs\" thing that confuses cvsimport, but I \nalso wonder if anybody has actually tried this before. With or without \nthe --bkcvs line, I get\n\n\tArgument \"28213 has collisions\" isn't numeric in addition (+) at /home/torvalds/bin/git-cvsimport-script line 600, line 1.\n\t* UNKNOWN LINE * PatchSet 28209 has collisions\n\t* UNKNOWN LINE * PatchSet 28194 has collisions\n\t* UNKNOWN LINE * PatchSet 28181 has collisions\n\t* UNKNOWN LINE * PatchSet 28180 has collisions\n\t...\n\nSadly, since I don't know perl, I can't tell whether this is a problem \nwith cvsps on the kernel, or the cvsimport perl script. I'm going to try \nmy old hacky C + shell alternative next just to see, but I thought I'd ask \nwhether people have tried this before and already know what's wrong.\n\nBtw, looking at what the perl script _seems_ to do, it does seem to do\ninsane things for the local CVS archive case. As far as I can tell from\nthe spaghetti that is perl, it uses a CVS server to handle even the local \nfile case, which just _can't_ be right. I realize you'd want to do that to \navoid connecting millions of times, but maybe it's better to use something \nlike cvsnup to download the whole thing, and then always use a local CVS \narchive?\n\n\t\t\tLinus\n"},{"id":"6447","messageId":"20050725234257.GC5680@kiste.smurf.noris.de","threadId":"1216","inReplyTo":"Pine.LNX.4.58.0507251544300.6074@g5.osdl.org","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-25T23:42:57Z","receivedAt":"2005-07-25T23:42:57Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nLinus Torvalds:\n> In particular, they always end up being imported as zero-sized empty\n> files, and will be filled in only later if that file is ever touched \n> again. In other words, the resulting git tree ends up being bogus.\n> \nThat's a problem with the bkcvs tree. Remember tht Bitkeeper does\nexactly the same thing -- the 1.0 version of *any* file is empty, and\ncontent appears only in version 1.1.\n\nWell, the bkcvs export preserved that ... \"feature\".\n\n(Side question - why aren't you doing a direct bk2git import?)\n\n> \tArgument \"28213 has collisions\" isn't numeric in addition (+) at /home/torvalds/bin/git-cvsimport-script line 600, line 1.\n\nThat's an output from cvsps that is not handled yet.\nIf you really need it I'll have to investigate.\n\n> Btw, looking at what the perl script _seems_ to do, it does seem to do\n> insane things for the local CVS archive case. As far as I can tell from\n> the spaghetti that is perl, it uses a CVS server to handle even the local \n> file case, which just _can't_ be right.\n\nSure it is, because ...\n\n> I realize you'd want to do that to \n> avoid connecting millions of times, but maybe it's better to use something \n> like cvsnup to download the whole thing, and then always use a local CVS \n> archive?\n\n... I don't have a sensible RCS library for perl (the code that I could\nfind is just a command line front-end). Fork+exec of some cvs checkout\ncommand per file is slower than just running a persistent CVS server.\n\nI've tried other ideas, but they run into problems because some\nidiots^Wpeople occasionally tag only parts of a CVS tree, or they do it\nat different times, and cvsps has to rearrange stuff in a way the CVS\nutilities don't understand, so any higher-level access than \"grab a\nbunch of files by their revision number and stick them into a commit\"\ndon't work in real life.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nPlease try to limit the amount of \"this room doesn't have any bazingas\"\nuntil you are told that those rooms are \"punched out.\" Once punched out,\nwe have a right to complain about atrocities, missing bazingas, and such.\n\t\t-- N. Meyrowitz\n"},{"id":"6452","messageId":"Pine.LNX.4.58.0507251922310.6074@g5.osdl.org","threadId":"1216","inReplyTo":"20050725234257.GC5680@kiste.smurf.noris.de","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-26T03:07:29Z","receivedAt":"2005-07-26T03:07:29Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Tue, 26 Jul 2005, Matthias Urlichs wrote:\n>\n> That's a problem with the bkcvs tree. Remember tht Bitkeeper does\n> exactly the same thing -- the 1.0 version of *any* file is empty, and\n> content appears only in version 1.1.\n\nNot really. That may be how the SCCS _deltas_ end up being done\ninternally, but it's definitely not how BK changesets work. \n\nFor example, in BK SCCS files (if I understood it correctly, I've not\nactually looked very closely) a \"rename\" ends up being two deltas - the\n\"diff\" delta and the \"rename\" delta. That does _not_ really mean that BK\nconsiders it two different things, it's purely a SCCS file layout thing, \nand it just shows through to bkcvs.\n\nSimilarly, apparently in SCCS the \"create\" event is one revision, and the\n\"initial data\" is another one, and again, that shows up in bkcvs even\nthough that's not really how BK works conceptually at all.\n\nSo then the cvs archives end up showing some of these things as multiple\nseparate patches, but that just means that cvsps doesn't understand that\nthey all get collapsed into one changeset in the bk model. The fact that\nsome changes may end up showing as multiple deltas is just a result of BK\nmostly re-using an old fileformat that just doesn't know anything at all\nabout changesets what-so-ever.\n\ncvsps should really have collapsed those things into _one_ changeset. I \nhad thought that it would do so automatically based on the date (the date \nshould always be exactly the same), but it turns out that since the log \nmessages might be different, cvsps will split _one_ ChangeSet into \nmultiple patches, which is _wrong_.\n\nIn fact, I guess the log messages _will_ be different, because the bkcvs \nthing will always put in the BK key in the \"real\" message.\n\nI _thought_ that this was exactly what the \"--bkcvs\" flag was going to\nnotice, but it seems to not be the case. Or maybe \"cvsimport\" just doesn't \npass that flag through.. In fact, I just checked, and \"cvsps --bkcvs\" \n_does_ do the right thing, and collapses all of these things to one \n\"PatchSet\".\n\nBut I think I see why \"git cvsimport\" does the wrong thing: since that one \ncommit has _all_ the deltas associated with the commit, it looks like \nthis:\n\n\tPatchSet 2\n\tDate: 2002/02/05 17:40:40\n\tAuthor: torvalds\n\tBranch: HEAD\n\tTag: v2_4_0\n\tLog:\n\tImport changeset\n\t\n\tBKrev: 3c601918i-Rse1XOIZxu4fPHUrTmmA\n\t\n\tMembers:\n\t COPYING:1.1->1.2\n\t COPYING:INITIAL->1.1\n\t CREDITS:1.1->1.2\n\t CREDITS:INITIAL->1.1\n\t ChangeSet:1.2->1.3\n\t MAINTAINERS:1.1->1.2\n\t\t....\n\nand notice how \"COPYING\" (and all other new files) has two deltas\nassociated with it, the \"INITIAL->1.1\" and the \"1.1->1.2\" one.\n\nAnd they are in the wrong order, so \"cvsimport\" ends up committing the \nlast one, which is the _empty_ one.\n\nNotice? We'll end up committing \"COPYING 1.1\" (the empty initial create)\neven though we _should_ have committed \"COPYING 1.2\" (the actual thing\nthat BK committed).\n\n> Well, the bkcvs export preserved that ... \"feature\".\n\nNo, the bkcvs thing exports an atomic BK commit as several deltas (with\nthe same date) not because it's a \"feature\" of BK, but partly because you\ncan't express what BK does in CVS, and partly because of what appears to\nbe purely internal BK implementation details (ie a feature of the SCCS\nfile).\n\nBK did it right, and we just imported it wrong.\n\nDavid - is there some way where cvsps could always order these things by \nrevision? I now realize that this is probably also what causes cvsps to \ncomplain about things like:\n\n\t..\n\tPatchSet 2 has collisions\n\t..\n\nwhich means that cvsps actually _saw_ this, but just output the result in \nthe wrong order as far as \"git cvsimport\" was concerned.\n\nThe preferred solution would be to always just suppress the older revision\nwhen you see multiple ones - it is by definition not interesting (you\ncannot actually ever access it even in the original BK tree).\n\n> (Side question - why aren't you doing a direct bk2git import?)\n\nBecause I don't have any BK trees left, and because I'm not going to touch\nAndrews code. We'd have had a portable BK export format (in fact, I wrote\none as a proof-of-concept thing when we were tryign to convince Tridge\nthat he really doesn't want to muck inside BK internals), but then shit \nhappens..\n\nSo I'll use the CVS thing. \n\n> > I realize you'd want to do that to \n> > avoid connecting millions of times, but maybe it's better to use something \n> > like cvsnup to download the whole thing, and then always use a local CVS \n> > archive?\n> \n> ... I don't have a sensible RCS library for perl (the code that I could\n> find is just a command line front-end). Fork+exec of some cvs checkout\n> command per file is slower than just running a persistent CVS server.\n\nFair enough, I suspect that without a builtin RCS library it really ends \nup being faster than the whole exec thing. \n\nI thought there was a RCS library (I know I got some hits for \"rcslib\" \nfor some scripting language and was cursing the fact that it wasn't for\nC), but I never really looked closer. I'm not surprised if the \"library\"\nends up just doing a \"system()\" thing.\n\n> I've tried other ideas, but they run into problems because some\n> idiots^Wpeople occasionally tag only parts of a CVS tree\n\nYeah, CVS really allows some very very annoying things that only work in a \nfile-at-a-time model.\n\n\t\tLinus\n"},{"id":"6453","messageId":"Pine.LNX.4.58.0507252028220.6074@g5.osdl.org","threadId":"1216","inReplyTo":"Pine.LNX.4.58.0507251922310.6074@g5.osdl.org","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-26T03:43:40Z","receivedAt":"2005-07-26T03:43:40Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Jul 2005, Linus Torvalds wrote:\n> \n> And they are in the wrong order, so \"cvsimport\" ends up committing the \n> last one, which is the _empty_ one.\n> \n> Notice? We'll end up committing \"COPYING 1.1\" (the empty initial create)\n> even though we _should_ have committed \"COPYING 1.2\" (the actual thing\n> that BK committed).\n\nDavid, how about a patch like this to cvsps? My very very limited testing\nseems to say that it does the right thing..\n\nIt's very simple: if we are adding the same file twice to the same \nPatchSet, we just look at the ordering of the revisions. If the revision \nwe're adding is older than the revision we already have, we just drop that \nrevision entirely. If it's the same, something is really wrong, and we add \nit to the \"collisions\" list. And if it's newer, then we remove the old \nrevision for that file, and add the new one instead.\n\nAs far as I can tell, the old code really was broken, since it would\nhappen to list different revisions in a random order when you had multiple\nchanges to the same file in the same patchset. This one always selects the\nlast one, which would seem to be the sane behaviour.\n\nAnd this all seem to make \"git cvsimport -p --bkcvs\" do the right thing. \n\n\t\tLinus\n\n---\ndiff --git a/cvsps.c b/cvsps.c\n--- a/cvsps.c\n+++ b/cvsps.c\n@@ -2384,8 +2384,31 @@ void patch_set_add_member(PatchSet * ps,\n for (next = ps->members.next; next != &ps->members; next = next->next) \n {\n \tPatchSetMember * m = list_entry(next, PatchSetMember, link);\n-\tif (m->file == psm->file && ps->collision_link.next == NULL) \n-\t\tlist_add(&ps->collision_link, &collisions);\n+\tif (m->file == psm->file) {\n+\t\tint order = compare_rev_strings(psm->post_rev->rev, m->post_rev->rev);\n+\n+\t\t/*\n+\t\t * Same revision too? Add it to the collision list\n+\t\t * if it isn't already.\n+\t\t */\n+\t\tif (!order) {\n+\t\t\tif (ps->collision_link.next == NULL)\n+\t\t\t\tlist_add(&ps->collision_link, &collisions);\n+\t\t\treturn;\n+\t\t}\n+\t\t\t\n+\t\t/*\n+\t\t * If this is an older revision than the one we already have\n+\t\t * in this patchset, just ignore it\n+\t\t */\n+\t\tif (order < 0)\n+\t\t\treturn;\n+\n+\t\t/*\n+\t\t * This is a newer one, remove the old one\n+\t\t */\n+\t\tlist_del(&m->link);\n+\t}\n }\n \n psm->ps = ps;\n"},{"id":"6454","messageId":"20050726042259.GG6098@mythryan2.michonline.com","threadId":"1216","inReplyTo":"20050725234257.GC5680@kiste.smurf.noris.de","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-26T04:22:59Z","receivedAt":"2005-07-26T04:22:59Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Tue, Jul 26, 2005 at 01:42:57AM +0200, Matthias Urlichs wrote:\n> (Side question - why aren't you doing a direct bk2git import?)\n\nThe last time I went looking for a tool to do this, I failed to find it\n- where can I get this?\n\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"6465","messageId":"Pine.LNX.4.58.0507260949140.19309@g5.osdl.org","threadId":"1216","inReplyTo":"Pine.LNX.4.58.0507252028220.6074@g5.osdl.org","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-26T16:50:59Z","receivedAt":"2005-07-26T16:50:59Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Jul 2005, Linus Torvalds wrote:\n> \n> David, how about a patch like this to cvsps? My very very limited testing\n> seems to say that it does the right thing..\n\nHmm.. David Mansfields address is bouncing, and it's apparently not just \nthat \"cvsps\" thing, since it says that the MX machine can't be looked up. \nDoes anybody have an alternate address for him? All the ones I've seen so \nfar with google are at the same failing \"dm.cobite.com\" address.\n\n\t\tLinus\n"},{"id":"6466","messageId":"42E675C9.4000504@lsrfire.ath.cx","threadId":"1216","inReplyTo":"Pine.LNX.4.58.0507260949140.19309@g5.osdl.org","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2005-07-26T17:41:29Z","receivedAt":"2005-07-26T17:41:29Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Linus Torvalds wrote:\n> Hmm.. David Mansfields address is bouncing, and it's apparently not just \n> that \"cvsps\" thing, since it says that the MX machine can't be looked up. \n> Does anybody have an alternate address for him? All the ones I've seen so \n> far with google are at the same failing \"dm.cobite.com\" address.\n\nLast message from him to this list came from david at \"cobite.com\" two\nmonths ago. Have you tried that one?\n\nRene\n"},{"id":"6469","messageId":"42E6AF1C.9050606@cobite.com","threadId":"1216","inReplyTo":"Pine.LNX.4.58.0507252028220.6074@g5.osdl.org","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"David Mansfield","fromEmail":"david@cobite.com","sentAt":"2005-07-26T21:46:04Z","receivedAt":"2005-07-26T21:46:04Z","isPatch":true,"sender":{"key":"david@cobite.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Mon, 25 Jul 2005, Linus Torvalds wrote:\n> \n>>And they are in the wrong order, so \"cvsimport\" ends up committing the \n>>last one, which is the _empty_ one.\n>>\n>>Notice? We'll end up committing \"COPYING 1.1\" (the empty initial create)\n>>even though we _should_ have committed \"COPYING 1.2\" (the actual thing\n>>that BK committed).\n> \n> \n> David, how about a patch like this to cvsps? My very very limited testing\n> seems to say that it does the right thing..\n> \n> It's very simple: if we are adding the same file twice to the same \n> PatchSet, we just look at the ordering of the revisions. If the revision \n> we're adding is older than the revision we already have, we just drop that \n> revision entirely. If it's the same, something is really wrong, and we add \n> it to the \"collisions\" list. And if it's newer, then we remove the old \n> revision for that file, and add the new one instead.\n> \n> As far as I can tell, the old code really was broken, since it would\n> happen to list different revisions in a random order when you had multiple\n> changes to the same file in the same patchset. This one always selects the\n> last one, which would seem to be the sane behaviour.\n> \n> And this all seem to make \"git cvsimport -p --bkcvs\" do the right thing. \n> \n\nI've been 'off the web' for a few weeks on vacation. I'll look at the \ncontext of the thread. It 'smells' wierd to have to revisions in the \nsame patchset at all, but I suppose you've all been through that before. \n So let me catch up with this thread and get back to you...\n\nDavid\n"},{"id":"6471","messageId":"Pine.LNX.4.58.0507261451240.19309@g5.osdl.org","threadId":"1216","inReplyTo":"42E6AF1C.9050606@cobite.com","subject":"Re: [PATCH] git-cvsimport-script: parse multidigit revisions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-26T22:01:00Z","receivedAt":"2005-07-26T22:01:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nAhh, the cobite.com address worked ;)\n\nDavid, as you may or may not be aware, the dm.cobite.com address was \nbouncing at least as of yesterday.\n\nOn Tue, 26 Jul 2005, David Mansfield wrote:\n> \n> It 'smells' wierd to have to revisions in the same patchset at all, but\n> I suppose you've all been through that before.\n\nIt seems to be just a result of how BK ends up having this internal notion\nof a \"delta\", and one commit can contain multiple deltas to the same file.\nThat's really just some BK internal implementation issue showing through -\nthe deltas really aren't even individually accessible, it's just that BK\nhas this two-stage commit thing where you first commit the individual file\nchanges (the \"delta\") and then you do the _real_ commit which gathers them\nall up.\n\nNormally you don't even see this at all, since the tools basically hide \nthis, but especially if you script things you'll see the difference.\n\nIn fact, in many ways the usage model when scripting ends up being a bit\nlike the git two-phase \"git-update-cache\" + \"git commit\" approach,\nalthough for totally different reasons. But unlike git, you can actually\ntell how somebody did several updates on the same file, and it seems to\nshow through in the bkcvs archives.\n\nI bet that it wasn't even intentional, and that it's really just a result\nof the bkcvs thing really just being pretty much a raw SCCS->RCS\ntranslation (with the addition of the \"changeset\" notion at a higher\nlevel).\n\nSo normally you'd not like to see this unless you use the --bkcvs flag,\nbut I suspect that with a big fuzz-factor and repeated commit messages you\ncan see it even with a perfectly normal CVS tree - if only because cvsps\nmight collapse two separate commits that shouldn't really be collapsed.\n\n\t\t\tLinus\n"}]}