{"thread":{"id":"2983","subject":"[PATCH] Teach cvsexportcommit to add new files","startedAt":"2006-01-06T20:54:41Z","lastAt":"2006-01-07T09:01:48Z","messageCount":4,"participants":["Yann Dirson","Junio C Hamano","Martin Langhoff"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"14200","messageId":"20060106205441.GA32585@nowhere.earth","threadId":"2983","inReplyTo":null,"subject":"[PATCH] Teach cvsexportcommit to add new files","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-01-06T20:54:41Z","receivedAt":"2006-01-06T20:54:41Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Teach cvsexportcommit to add new files\n\"cvs add\" support was already there, but the \"unknown\" status\nreturned when querying a file not yet known to cvs caused the\nscript to abort prematurely.\n\n---\ncommit 7e1b8a9af653c9a4f8d2a6a4b34ccf56a2f48526\ntree f94f057ec672b715ffda28e359bd5d672fdfb6b3\nparent 58e3fb40f7ca1c28f9105c15166884f80bb22e55\nauthor Yann Dirson Fri, 06 Jan 2006 21:31:21 +0100\ncommitter Yann Dirson Fri, 06 Jan 2006 21:31:21 +0100\n\n git-cvsexportcommit.perl | 12 ++++++++++--\n 1 files changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl\nindex 5a8c011..d5fbee7 100755\n--- a/git-cvsexportcommit.perl\n+++ b/git-cvsexportcommit.perl\n@@ -103,8 +103,16 @@ undef @files; # don't need it anymore\n \n # check that the files are clean and up to date according to cvs\n my $dirty;\n-foreach my $f (@afiles, @mfiles, @dfiles) {\n- # TODO:we need to handle removed in cvs and/or new (from git) \n+foreach my $f (@afiles) {\n+ my $status = `cvs -q status \"$f\" | grep '^File: '`;\n+\n+ unless ($status =~ m/Status: Unknown$/) {\n+\t$dirty = 1;\n+\twarn \"File $f is already known in your CVS checkout!\\n\";\n+ }\n+}\n+foreach my $f (@mfiles, @dfiles) {\n+ # TODO:we need to handle removed in cvs\n my $status = `cvs -q status \"$f\" | grep '^File: '`;\n \n unless ($status =~ m/Status: Up-to-date$/) {\n\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"14203","messageId":"7virsxrnik.fsf@assigned-by-dhcp.cox.net","threadId":"2983","inReplyTo":"20060106205441.GA32585@nowhere.earth","subject":"Re: [PATCH] Teach cvsexportcommit to add new files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-06T22:37:39Z","receivedAt":"2006-01-06T22:37:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yann Dirson writes:\n\n> Teach cvsexportcommit to add new files\n> \"cvs add\" support was already there, but the \"unknown\" status\n> returned when querying a file not yet known to cvs caused the\n> script to abort prematurely.\n\nThanks. I'll take the patch as is, but I noticed that the\ncvsexportcommit still has some room for polishing.\n\n * The command is to be run from CVS working copy (as desribed\n in the documentation) and seems to assume that the parent\n commit is checked out at least for the paths involved between\n the commit and the parent (not clearly documented).\n\n * I wonder if it is safe with filenames with embedded SP?\n\n * This undef @files seem premature; later you will say\n cleanupcvs(@files) won't you?\n\n> $opt_v && print \"The commit affects:\\n \";\n> $opt_v && print join (\"\\n \", @afiles,@mfiles,@dfiles) . \"\\n\\n\";\n> undef @files; # don't need it anymore\n> ...\n> ### NOTE: if you are planning to die() past this point\n> ### you MUST call cleanupcvs(@files) before die()\n\n * I think this grep '^Binary' is unsafe; different versions of\n gnu diff say just \"Files differ\".\n\n> print \"'Patching' binary files\\n\";\n> \n> my @bfiles = `git-diff-tree -p $parent $commit | grep '^Binary'`;\n\n * ls-tree can take $parent (a commit which is by definition a\n treeish) happily here, so rev-parse is not needed.\n\n> my $tree = `git-rev-parse $parent^{tree} `;\n> chomp $tree;\n> my $blob = `git-ls-tree $tree \"$f\" | cut -f 1 | cut -d ' ' -f 3`;\n> chomp $blob;\n\n * another way would be git-hash-object (without -w) the working\n tree file (which you already know matches the $parent\n version) and compare the hash with $blob without extracting\n it with cat-file.\n\n> `git-cat-file blob $blob > $tmpdir/blob`;\n> `cmp -q $f $tmpdir/blob`;\n\nI am getting an impression that _if_ we care about applying\nfuzzy patch like this, giving fuzz feature to git-apply would\nhelp this program somewhat, but at the same time I do not think\nof a good reason to even accept nonexact patch when synching two\nSCM histories.\n"},{"id":"14226","messageId":"46a038f90601062329s35163616i7c658e4d6ede294b@mail.gmail.com","threadId":"2983","inReplyTo":"7virsxrnik.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach cvsexportcommit to add new files","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-07T07:29:08Z","receivedAt":"2006-01-07T07:29:08Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/7/06, Junio C Hamano wrote:\n> Yann Dirson writes:\n>\n> > Teach cvsexportcommit to add new files\n> > \"cvs add\" support was already there, but the \"unknown\" status\n> > returned when querying a file not yet known to cvs caused the\n> > script to abort prematurely.\n>\n> Thanks. I'll take the patch as is, but I noticed that the\n> cvsexportcommit still has some room for polishing.\n\nDefinitely. It's a bit of a hack job that I got started with, and as\nit's /worked for me/ so far, haven't done much with it. I am actually\nquite busy at the moment, so I don't think you'll see many patches\nfrom me on this fron yet...\n\n(BTW: I'm hoping to find a bit of time to code the git-cvsdaemon that\nI've mentioned before, which would be a hell of an interesting\naddition, methinks.)\n\n> * The command is to be run from CVS working copy (as desribed\n> in the documentation) and seems to assume that the parent\n> commit is checked out at least for the paths involved between\n> the commit and the parent (not clearly documented).\n\nIndeed, and you can also use it for the same thing you'd use git-am --\nfor instance, to \"merge into CVS\" feature branches kept on GIT.\n\n> * I wonder if it is safe with filenames with embedded SP?\n\nIt's not -- shame on me. Backticks should be replaced with\nsafe_pipe_capture() as Eric's done on git-archimport.\n\n> * I think this grep '^Binary' is unsafe; different versions of\n> gnu diff say just \"Files differ\".\n\nUnsure how to detect binary files safely. Is there a way to ask git\nwhether it considers the files to be binary?\n\n(snipped several good suggestions here...)\n\n> I am getting an impression that _if_ we care about applying\n> fuzzy patch like this, giving fuzz feature to git-apply would\n> help this program somewhat, but at the same time I do not think\n> of a good reason to even accept nonexact patch when synching two\n> SCM histories.\n\nWell, with some fuzz you can use this to merge something into CVS even\nif the trunk or branch you're merging into has moved forward a bit.\nOTOH, I guess you can go back to git and do a git-rebase if needed.\n\ncheers,\n\n\nmartin\n"},{"id":"14234","messageId":"20060107090148.GB32585@nowhere.earth","threadId":"2983","inReplyTo":"46a038f90601062329s35163616i7c658e4d6ede294b@mail.gmail.com","subject":"cvsexportcommit / cvsimport issues","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-01-07T09:01:48Z","receivedAt":"2006-01-07T09:01:48Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Jan 07, 2006 at 08:29:08PM +1300, Martin Langhoff wrote:\n> Definitely. It's a bit of a hack job that I got started with, and as\n> it's /worked for me/ so far, haven't done much with it. I am actually\n> quite busy at the moment, so I don't think you'll see many patches\n> from me on this fron yet...\n\nIn any case, I'm likely to send occasional patches as I hit the\nlimitations.\n\n> Indeed, and you can also use it for the same thing you'd use git-am --\n> for instance, to \"merge into CVS\" feature branches kept on GIT.\n\nThat's also the way I use it. We have an official CVS repo, and I'm\ndoing all of my work in git, until it's ready for publication in the\ncentral CVS repo.\n\n\n\nWhile we're talking about cvs<->git, I also hit a couple of problems\nwith git-cvsimport, which I did not have time to fully investigate:\n\n- when there are very large files in the CVS repo (eg. a 85MB\ntarball), cvsimport timeouts while fetching it (saying the server has\ngone away), when accesing via pserver or ssh. I tried to play with\nthe socket timeout, but also it helped to reproducibly import a 15MB\nfile, I could not raise it enough to get the 85MB file.\n\nHunting for this problem, I found myself asking the question, why it\nwas chosen in the first place to implement a cvs client, instead of\nusing the reference implementation.\n\nI was finally able to workaround this by transfering a copy of the\ncvsroot to the local machine, but that's not quite practical :)\n\n\n- the \"-k\" flag is dangerous as-is, since it overrides any flag\n(eg. -kb) set on the files in the cvs repo. I got a plain\n(non-compressed) tarball of sources corrupted because of this, and was\nsubsequently unable to use -k at all. Fortunately, I had done the\noriginal cvs imports using -ko, so it was not a problem for me, but we\nmay want to fix the issue eventually, and at least document this\ncaveat.\n\n\n- when doing an incremental import using -P, where the 1st patchset\nwas just a module creation with a single .cvsignore to allow creation\nof a pseudo-vendor-branch, and the 2nd patchset was an import on the\nsaid branch, cvsimport complained that it could not find the branch in\nmy git repo, and I had to create it manually, whereas while importing\nall patchsets in one batch, the branch was created without manual\nintervention (but import subsequently failed because of the big file\nas mentionned above). Similarly, still when using -P, using the local\nrepository copy, importing the initial patchset complained 'cannot\nfind \"origin\"' - I prefered to do this initial import using the\npserver access, which worked fine, and did the later imports via the\nlocal repo.\n\nWe could thus want to mention in the doc that -P can also be used to\nhelp circumvent problems by using for each patchset the most adequate\nimport method :)\n\n\n- as of cvsps 2.1, patchsets only contain a single tag, even when\nthere are several of them on the cvs repo. We should surely document\nthis shortcoming so people do not get caught by surprise.\n\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"}]}