{"thread":{"id":"719","subject":"new cvsps version fixes issues for cvs2git","startedAt":"2005-05-26T04:02:53Z","lastAt":"2005-05-26T04:35:07Z","messageCount":3,"participants":["David Mansfield","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3971","messageId":"42954A6D.6020503@cobite.com","threadId":"719","inReplyTo":null,"subject":"new cvsps version fixes issues for cvs2git","fromName":"David Mansfield","fromEmail":"david@cobite.com","sentAt":"2005-05-26T04:02:53Z","receivedAt":"2005-05-26T04:02:53Z","isPatch":false,"sender":{"key":"david@cobite.com","avatar":null},"body":"Hi,\n\nI just put out the 2.1 tarball on \nhttp://www.cobite.com/cvsps/cvsps-2.1.tar.gz.  I tested it out with the \nsyslinux, mutt, and a bunch of my own repos.  It fixes the following \nissues that were causing some of the problems with cvs2git:\n\n1) proper detection and reporting of branch ancestry, with the -A \noption.  This patch was sent under separate cover, but now I also \nexplicitly disallow the bogus 'import' branch from being an ancestor. \nThe ancestor will only be reported when a new branch appears.\n\n2) patchset ordering problems.  actual revision ancestry is considered \nwhen ordering the patchsets.  this mainly affects the 'patchset 1 and \npatchset 2 are swapped' problem, but could be others\n\n3) patchset 'globbing' problems.  previously, cvsps would allow the same \nfile into a patchset more than once.  this is clearly bogus, and now it \nisn't allowed, combined with #2 and some minor date tweaking, the \nordering should be 'more perfect than ever.'\n\n4) patchset date/time problems.  the date/time handling was bogus.  some \nof it was patched for some time in my tree, but not released.  also we \nnow report all dates in LOCALTIME.  use the TZ variable to get a \ndifferent time.  Note: 'cvs log' format is always UTC.\n\nLinus, based on #4, you may want to set 'export TZ=UTC' before running, \nand handle date/time conversion in cvs2git counting on that.  otherwise, \nI think problems may occur with daylight savings (apr/oct).\n\nIf there are any remaining issues, let me know.\n\nDavid\n"},{"id":"3972","messageId":"Pine.LNX.4.58.0505252111580.2307@ppc970.osdl.org","threadId":"719","inReplyTo":"42954A6D.6020503@cobite.com","subject":"Re: new cvsps version fixes issues for cvs2git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-26T04:20:44Z","receivedAt":"2005-05-26T04:20:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 May 2005, David Mansfield wrote:\n> \n> 4) patchset date/time problems.  the date/time handling was bogus.  some \n> of it was patched for some time in my tree, but not released.  also we \n> now report all dates in LOCALTIME.  use the TZ variable to get a \n> different time.  Note: 'cvs log' format is always UTC.\n> \n> Linus, based on #4, you may want to set 'export TZ=UTC' before running, \n> and handle date/time conversion in cvs2git counting on that.  otherwise, \n> I think problems may occur with daylight savings (apr/oct).\n\ncvs2git only wants UTC times, and doesn't do any conversion, since that's\nthe native git format (git considers all times to be UTC, but also records\na \"what timezone was the thing done in\" so that if you want to, you can\nprint it out not in localtime, but in \"localtime as it was for the\ncommitter\"). Nothing else really makes sense - it's totally senseless to \nprint it out as \"in localtime of user\".\n\nSince the CVS information doesn't contain any timezone, it would be bogus\nto use one, and the only sane git conversion is to always use UTC. Using \nthe timezone of the converter is also bogus, since that just makes \ndifferent converters get different results.\n\nSo I'd much rather see you add a flag that just always does the native CVS\ntime (ie UTC)?  Quite frankly, it's wrong to do anything else, exactly\nbecause it makes no sense to print out dates in a timezone that has no\nrelevance (what relevance does Pacitic time have for somebody who\ncommitted something at 8AM Eastern? _None_).\n\nThe fact is, if we depend on people doign \"TZ=UTC\", people will forget, \nand then people will have different conversions.\n\n(My personal preference would be to _default_ to UTC, and instead have a\nspecial flag that says \"use localtime to print stuff out\", since \nlocaltime really is the least relevant one most of the time)\n\n\t\t\tLinus\n"},{"id":"3973","messageId":"429551FB.60601@cobite.com","threadId":"719","inReplyTo":"Pine.LNX.4.58.0505252111580.2307@ppc970.osdl.org","subject":"Re: new cvsps version fixes issues for cvs2git","fromName":"David Mansfield","fromEmail":"david@cobite.com","sentAt":"2005-05-26T04:35:07Z","receivedAt":"2005-05-26T04:35:07Z","isPatch":false,"sender":{"key":"david@cobite.com","avatar":null},"body":"\n> \n> Since the CVS information doesn't contain any timezone, it would be bogus\n> to use one, and the only sane git conversion is to always use UTC. Using \n> the timezone of the converter is also bogus, since that just makes \n> different converters get different results.\n\nThe cvs log is now properly handled as UTC.  It wasn't before.  That's \none good thing.  And yes, git conversion better always be UTC, no \nargument here.\n\n> \n> So I'd much rather see you add a flag that just always does the native CVS\n> time (ie UTC)?  Quite frankly, it's wrong to do anything else, exactly\n> because it makes no sense to print out dates in a timezone that has no\n> relevance (what relevance does Pacitic time have for somebody who\n> committed something at 8AM Eastern? _None_).\n\nIt will always print in the localtime of the user running cvsps, not the \ntimezone of the commiter (in fact, we don't know the timezone of the \ncommitter at all).  I hate committing something, running cvsps and \nhaving it tell me I'm about to commit in five hours, but I *do* see your \npoint.\n\n> \n> The fact is, if we depend on people doign \"TZ=UTC\", people will forget, \n> and then people will have different conversions.\n\nThat's true, that would be terrible.  But I'm arguing that the actual \nconversion program (which actually wants machine readable output) should \nmake it happen.  If that means we need a shell-script wrapper than \nso-be-it.  By letting cvsps display in any timezone, including UTC, it \ncan work for everyone (keep the policy out of the program).\n\n> (My personal preference would be to _default_ to UTC, and instead have a\n> special flag that says \"use localtime to print stuff out\", since \n> localtime really is the least relevant one most of the time)\n> \n\nThe thing you may be missing (and, hey, why not?) is that some people \nwill actually still be using cvs, and cvsps to them is a tool that \nproduces output for humans.  For you, it is a stone in the path to git's \ndomination of the world.\n\nI'll have to think about it.  At the very least a flag requesting UTC, \nor a flag requesting localtime makes sense.  Setting environment \nvariables and then running a program always seemed a bit like abuse of \nglobal variables.\n\nDavid\n\n"}]}