{"thread":{"id":"14897","subject":"[QGIT RFC] Unit tests for QGit","startedAt":"2008-08-08T21:13:18Z","lastAt":"2008-08-29T07:01:48Z","messageCount":17,"participants":["Jan Hudec","Benjamin Sergeant","Marco Costalba","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86548","messageId":"20080808211318.GA4396@efreet.light.src","threadId":"14897","inReplyTo":null,"subject":"[QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-08T21:13:18Z","receivedAt":"2008-08-08T21:13:18Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello Marco and others,\n\nI've been thinking about some refactoring of QGit since some time. And to be\nsure I don't screw up things too hard in the process, I thought about adding\na test suite infrastructure first (and add some test cases for each think\njust before refactoring it).\n\nThe problem is, that implementing unittests means I need to compile\n2 separate binaries -- qgit itself and the test -- using most (but not all)\nof the same sources. I see two ways to do it, so I'd like to ask which you\nconsider cleaner:\n\n 1. Reorganize stuff so that a (static) library is created from all the\n sources except qgit.cpp and than qgit.cpp is linked to this library to\n create qgit and the tests are linked with it to provide the test runner.\n\n Pros:\n - The .pro files should remain reasonably simple.\n - The sources are only compiled once.\n Cons:\n - Need to split the src directory to two, so bigger moving stuff around.\n\n 2. Put the list of sources into file included in the src.pro and include it\n in the tests.pro file too.\n\n Pros:\n - No libraries and stuff\n - Less moving stuff around.\n Cons:\n - The sources actually get compiled twice, once for the tests and once\n for the qgit binary.\n - Paths to the sources need to be manually adjusted after including into\n the .pro files, making the .pro files rather ugly.\n\nThere seems to be no solution requiring less changes to the projects, because\nqmake can only create one library or executable per directory and including\nfiles from other directory is not supported to well.\n\nI've already done the later (have patch series ready), but I am now thinking\nthat I should probably redo it the first way. What do you think. Does it make\nsense to do that?\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"86556","messageId":"1621f9fa0808081600i51bcaaedtc22a7a85947ba400@mail.gmail.com","threadId":"14897","inReplyTo":"20080808211318.GA4396@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Benjamin Sergeant","fromEmail":"bsergean@gmail.com","sentAt":"2008-08-08T23:00:57Z","receivedAt":"2008-08-08T23:00:57Z","isPatch":false,"sender":{"key":"bsergean@gmail.com","avatar":null},"body":"On Fri, Aug 8, 2008 at 2:13 PM, Jan Hudec wrote:\n> Hello Marco and others,\n>\n> I've been thinking about some refactoring of QGit since some time. And to be\n> sure I don't screw up things too hard in the process, I thought about adding\n> a test suite infrastructure first (and add some test cases for each think\n> just before refactoring it).\n>\n> The problem is, that implementing unittests means I need to compile\n> 2 separate binaries -- qgit itself and the test -- using most (but not all)\n> of the same sources. I see two ways to do it, so I'd like to ask which you\n> consider cleaner:\n>\n> 1. Reorganize stuff so that a (static) library is created from all the\n> sources except qgit.cpp and than qgit.cpp is linked to this library to\n> create qgit and the tests are linked with it to provide the test runner.\n>\n> Pros:\n> - The .pro files should remain reasonably simple.\n> - The sources are only compiled once.\n> Cons:\n> - Need to split the src directory to two, so bigger moving stuff around.\n>\n> 2. Put the list of sources into file included in the src.pro and include it\n> in the tests.pro file too.\n>\n> Pros:\n> - No libraries and stuff\n> - Less moving stuff around.\n> Cons:\n> - The sources actually get compiled twice, once for the tests and once\n> for the qgit binary.\n> - Paths to the sources need to be manually adjusted after including into\n> the .pro files, making the .pro files rather ugly.\n>\n> There seems to be no solution requiring less changes to the projects, because\n> qmake can only create one library or executable per directory and including\n> files from other directory is not supported to well.\n>\n> I've already done the later (have patch series ready), but I am now thinking\n> that I should probably redo it the first way. What do you think. Does it make\n> sense to do that?\n>\n> --\n> Jan 'Bulb' Hudec \n> --\n\nMaybe you can have a look at QTestLib. But it won't solve your\nbuildsystem issues. You'll need one .pro per test. (I have one .pro\nper test plus one directory per test). There's probably other ways to\nusing it.\n\nhttp://doc.trolltech.com/4.4/qtestlib-manual.html#qtestlib\n"},{"id":"86639","messageId":"20080810075557.GA3955@efreet.light.src","threadId":"14897","inReplyTo":"1621f9fa0808081600i51bcaaedtc22a7a85947ba400@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-10T07:55:57Z","receivedAt":"2008-08-10T07:55:57Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Aug 08, 2008 at 16:00:57 -0700, Benjamin Sergeant wrote:\n> On Fri, Aug 8, 2008 at 2:13 PM, Jan Hudec wrote:\n> > I've been thinking about some refactoring of QGit since some time. And to be\n> > sure I don't screw up things too hard in the process, I thought about adding\n> > a test suite infrastructure first (and add some test cases for each think\n> > just before refactoring it).\n> >\n> > The problem is, that implementing unittests means I need to compile\n> > 2 separate binaries -- qgit itself and the test -- using most (but not all)\n> > of the same sources. I see two ways to do it, so I'd like to ask which you\n> > consider cleaner:\n> > [...]\n> \n> Maybe you can have a look at QTestLib. But it won't solve your\n\nSure I did. Unfortunately they don't suggest any good way to handle your\nbuild process with it in their examples. Seems to me they never tried testing\nan application with it.\n\nI plan to go down the QTestLib route. Maybe it could be combined with\nLDTP[1] for blackbox testing -- they claim to be able to use Qt 4's\naccessibility to control an application.\n\n> buildsystem issues. You'll need one .pro per test. (I have one .pro\n> per test plus one directory per test). There's probably other ways to\n> using it.\n\nDepends on what you call a test. But generally there should be no reason to\nhave more than one .pro file for all tests. You just need to manually\nmaintain a list of test classes or create some kind of static instance\nself-registration (which I did).\n\n> http://doc.trolltech.com/4.4/qtestlib-manual.html#qtestlib\n\n[1] http://ldtp.freedesktop.org/\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"87418","messageId":"e5bfff550808170157m45532428y3956e5d0d92e97d9@mail.gmail.com","threadId":"14897","inReplyTo":"20080808211318.GA4396@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-17T08:57:36Z","receivedAt":"2008-08-17T08:57:36Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Fri, Aug 8, 2008 at 10:13 PM, Jan Hudec wrote:\n> Hello Marco and others,\n>\n\nHi Jan,\n\n sorry to reply so late but I just returned from holiday (no PC there\ndue to it was severely forbidden by my boss aka wife :-)\n\n\n> I've been thinking about some refactoring of QGit since some time. And to be\n> sure I don't screw up things too hard in the process, I thought about adding\n> a test suite infrastructure first (and add some test cases for each think\n> just before refactoring it).\n>\n\nThat's interesting. I have NO experience on test suites for GUI\napplications (command line applications like git I would think are\neasier to setup some tests suite for)\n\n\n> The problem is, that implementing unittests means I need to compile\n> 2 separate binaries -- qgit itself and the test -- using most (but not all)\n> of the same sources. I see two ways to do it, so I'd like to ask which you\n> consider cleaner:\n>\n> 1. Reorganize stuff so that a (static) library is created from all the\n> sources except qgit.cpp and than qgit.cpp is linked to this library to\n> create qgit and the tests are linked with it to provide the test runner.\n>\n> Pros:\n> - The .pro files should remain reasonably simple.\n> - The sources are only compiled once.\n> Cons:\n> - Need to split the src directory to two, so bigger moving stuff around.\n>\n\nThis is not a cons IMHO if it helps in separating tests from sources.\n\nAs I said I am no expert, but I would try to\n\n- Let the test suite be easily stripped/not compiled for the\npublishing (remember that we have to produce also that little\nqgit_install.exe file used on *that* OS)\n\n- Let the test be compiled only on demand (during developing I just\nwant to compile and run as few things as possible: C++ is already\nquite bad in that regard and I don't want the situation get worst. BTW\nI consider C++ slow compile times the biggest and probably only\ndrawback of C++ against C for big projects)\n\n- Try to find some literature/reference before starting coding. As I\nsaid I am no expert of GUI testing, so I would probably try to find\nsome Qt projects that use it and see/ask the developers how they\nmanaged to do that and what are the problems. Then try to be stick to\nknown best practice (read someone that has DONE that in a REAL\nproject, not someone that has WRITTEN about that in a paper or a\nvendor marketing/documentation)\n\nAnyhow I'm really interested in this thing, and hope to see your work\nsoon. Please feel free to drop me a line for any help you think I can\ngive you.\n\nBye\nMarco\n"},{"id":"87444","messageId":"20080817141530.GA4542@efreet.light.src","threadId":"14897","inReplyTo":"e5bfff550808170157m45532428y3956e5d0d92e97d9@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-17T14:15:30Z","receivedAt":"2008-08-17T14:15:30Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Aug 17, 2008 at 09:57:36 +0100, Marco Costalba wrote:\n> On Fri, Aug 8, 2008 at 10:13 PM, Jan Hudec wrote:\n> sorry to reply so late but I just returned from holiday (no PC there\n> due to it was severely forbidden by my boss aka wife :-)\n\nThat's all right. I am not progressing that fast.\n\n> > I've been thinking about some refactoring of QGit since some time. And to be\n> > sure I don't screw up things too hard in the process, I thought about adding\n> > a test suite infrastructure first (and add some test cases for each think\n> > just before refactoring it).\n> That's interesting. I have NO experience on test suites for GUI\n> applications (command line applications like git I would think are\n> easier to setup some tests suite for)\n\nWell, there are basically three points at which GUI application can be\ntested:\n 1. The code that provides data does not directly do anything with graphics\n and therefore can be tested by normal unittests. In this case such tests\n can be written for the Git and related classes.\n 2. Widget events can be emulated inside the test driver, for which Qt4\n contains a (quite basic but usable) QTestlib module. The tests work as\n normal unittests.\n 3. User interaction can be simulated from outside the application, eg. with\n LDTP.\n\nI actually plan the first two items. While the third would be less invasive\n(no need to link anything anywhere), unittests are much more useful for\ndebugging, because you can test individual functions independently.\n\n> > The problem is, that implementing unittests means I need to compile\n> > 2 separate binaries -- qgit itself and the test -- using most (but not all)\n> > of the same sources. I see two ways to do it, so I'd like to ask which you\n> > consider cleaner:\n> >\n> > 1. Reorganize stuff so that a (static) library is created from all the\n> > sources except qgit.cpp and than qgit.cpp is linked to this library to\n> > create qgit and the tests are linked with it to provide the test runner.\n> >\n> > Pros:\n> > - The .pro files should remain reasonably simple.\n> > - The sources are only compiled once.\n> > Cons:\n> > - Need to split the src directory to two, so bigger moving stuff around.\n> >\n> \n> This is not a cons IMHO if it helps in separating tests from sources.\n\nThe tests would be a separate directory in any case. What I will need to\nseparate is qgit.cpp from all other sources. So there will be *three* folders\nin the end -- one for linking the qgit binary, containing only qgit.cpp and\na .pro file, one for the majority of source and one for linking the testsuite\nwith the test sources.\n\n> As I said I am no expert, but I would try to\n> \n> - Let the test suite be easily stripped/not compiled for the\n> publishing (remember that we have to produce also that little\n> qgit_install.exe file used on *that* OS)\n\nThe test suite basically must be a separate binary. At least that's the only\nmethod I ever used -- it would be possible to link everything together and\nstart the test suite using a parameter, but I don't intend to do that.\n\n> - Let the test be compiled only on demand (during developing I just\n> want to compile and run as few things as possible: C++ is already\n> quite bad in that regard and I don't want the situation get worst. BTW\n> I consider C++ slow compile times the biggest and probably only\n> drawback of C++ against C for big projects)\n\nYes, you can just comment out the tests. On the other hand it's during the\ndevelopment I normally want to run the tests. I usually prefer to write\na test for things I work on over starting the user interface and testing them\nmanually, because manual testing is much more prone to forgetting some\nimportant corner cases.\n\n> - Try to find some literature/reference before starting coding. As I\n> said I am no expert of GUI testing, so I would probably try to find\n> some Qt projects that use it and see/ask the developers how they\n> managed to do that and what are the problems. Then try to be stick to\n> known best practice (read someone that has DONE that in a REAL\n> project, not someone that has WRITTEN about that in a paper or a\n> vendor marketing/documentation)\n\nWell, KDE people talked about doing it, but I am not sure how much they\nactually do. But it's really just normal unit-testing.\n\n> Anyhow I'm really interested in this thing, and hope to see your work\n> soon. Please feel free to drop me a line for any help you think I can\n> give you.\n\nBye,\nJan\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"87445","messageId":"e5bfff550808170846y522cc6a8w59b696be39df311b@mail.gmail.com","threadId":"14897","inReplyTo":"20080808211318.GA4396@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-17T15:46:34Z","receivedAt":"2008-08-17T15:46:34Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Fri, Aug 8, 2008 at 10:13 PM, Jan Hudec wrote:\n\n>\n> I've already done the later (have patch series ready), but I am now thinking\n> that I should probably redo it the first way. What do you think. Does it make\n> sense to do that?\n>\n\nCould you please post somewhere the patches ?\n\nBetter yet to fork from http://repo.or.cz/w/qgit4.git and set up your\ntree on http://repo.or.cz/ host (it's easy and fast, thanks Peter :-)\n\nI can check that and eventually pulling from that.\n\nAs a general rule if you have already done a good chunk of work with\nunit test patches I would avoid to ask you to redo in a different way,\nso I would say it does not make a lot of sense to me at least before\nlooking at the code.\n\n\nMarco\n\nP.S: I have played a bit with qmake some time ago (to set-up the\ndouble build environment Windows/Linux) so perhaps I could help you in\nfinding some useful trick to avoid the cons regarding .pro files you\nposted. But of course I first need to see the patches.\n"},{"id":"87455","messageId":"20080817195839.GB4542@efreet.light.src","threadId":"14897","inReplyTo":"e5bfff550808170846y522cc6a8w59b696be39df311b@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-17T19:58:39Z","receivedAt":"2008-08-17T19:58:39Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Aug 17, 2008 at 16:46:34 +0100, Marco Costalba wrote:\n> On Fri, Aug 8, 2008 at 10:13 PM, Jan Hudec wrote:\n> > I've already done the later (have patch series ready), but I am now thinking\n> > that I should probably redo it the first way. What do you think. Does it make\n> > sense to do that?\n> \n> Could you please post somewhere the patches ?\n\nI only have the basic infrastructure (building and basic runner) ready, while\nI am trying to figure out how individual parts of QGit are supposed to work.\nBut I can publish that, yes.\n\nWe had a very busy time at work lately, so I didn't get to it much. I'll try\nto write some tests soon.\n\n> Better yet to fork from http://repo.or.cz/w/qgit4.git and set up your\n> tree on http://repo.or.cz/ host (it's easy and fast, thanks Peter :-)\n> \n> I can check that and eventually pulling from that.\n\nMakes sense. git://repo.or.cz/qgit4/bulb.git\n\nBut as I said, I only have basic infrastructure and am currently looking at\nwhat to write tests for and how exactly that test should work. The detection\nof git vs. stgit branch (does not work for me) is likely first candidate, but\nthat is not UI thing. Maybe the effects of that option on the UI are the next\n(I would like to make them more localized somehow, though I don't know how\nyet). Other likely candidate would be anything which could be affected by\nfunny filenames (containing spaces, newlines, quotes, backslashes, control\nchars and such).\n\n> As a general rule if you have already done a good chunk of work with\n> unit test patches I would avoid to ask you to redo in a different way,\n> so I would say it does not make a lot of sense to me at least before\n> looking at the code.\n\nI was testing what can be done so far. So now I decided to go the library way\n(in scons or manually written makefiles I would just re-link the same .o\nfiles, but qmake does not seem to allow that) to avoid double compilation.\n\n> Marco\n> \n> P.S: I have played a bit with qmake some time ago (to set-up the\n> double build environment Windows/Linux) so perhaps I could help you in\n> finding some useful trick to avoid the cons regarding .pro files you\n> posted. But of course I first need to see the patches.\n\nWell, I somehow managed -- except I am not sure I dealed with the windows\npart correctly. What could be improved is maybe if you know how to signal\na dependency between two projects. I currently rely on the top-level makefile\nalways calling the subdirs in the order they are specified, but I fear\nportable recursive make does not really offer any better solution, so qmake\ncan't really do that either.\n\nUnfortunately while Qt is generally documented quite well, qmake\ndocumentation is not so good.\n\nNote: I think I found a bug in qmake here -- when you run qmake at top level,\nthe makefile will call qmake in subdirectories to create makefiles there, but\nthe rule has no dependencies, so it will not remake the makefiles when the\n.pro files change there.\n\nAlso I don't understand why you set 'MAKEFILE = qmake' in the src/src.pro --\nit does not seem to be respected, at least when I call it through the\ntop-level qgit.pro (which I now have to when there are 3 subdirs).\n\nRegards,\nJan\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"87459","messageId":"e5bfff550808171330w28dda6a2m32b0e51b1ef73cdc@mail.gmail.com","threadId":"14897","inReplyTo":"20080817195839.GB4542@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-17T20:30:46Z","receivedAt":"2008-08-17T20:30:46Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Sun, Aug 17, 2008 at 8:58 PM, Jan Hudec wrote:\n>\n> But as I said, I only have basic infrastructure and am currently looking at\n> what to write tests for and how exactly that test should work. The detection\n> of git vs. stgit branch (does not work for me)\n\nThis sounds as a bug. Could you elaborate on that please ?\n\n\nBTW the test for a StGit repo is:\n\nisStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n\nin function Git::getRefs() , file git_startup.cpp\n\n\n>\n> Well, I somehow managed -- except I am not sure I dealed with the windows\n> part correctly. What could be improved is maybe if you know how to signal\n> a dependency between two projects. I currently rely on the top-level makefile\n> always calling the subdirs in the order they are specified, but I fear\n> portable recursive make does not really offer any better solution, so qmake\n> can't really do that either.\n>\n\nCould the following help ?\n\nhttp://lists.trolltech.com/qt4-preview-feedback/2004-10/thread00174-0.html\n\n>\n> Note: I think I found a bug in qmake here -- when you run qmake at top level,\n> the makefile will call qmake in subdirectories to create makefiles there, but\n> the rule has no dependencies, so it will not remake the makefiles when the\n> .pro files change there.\n>\n\nI knew that. For my use I always delete Makefiles after modifying any\nof *.pro files, I'm sure it exists a better way but honestly I didn't\ninvestigate too much on this.\n\n> Also I don't understand why you set 'MAKEFILE = qmake' in the src/src.pro --\n> it does not seem to be respected, at least when I call it through the\n> top-level qgit.pro (which I now have to when there are 3 subdirs).\n>\n\n>From http://doc.trolltech.com/4.0/qmake-variable-reference.html#makefile\n\nMAKEFILE\nThis variable specifies the name of the Makefile which qmake should\nuse when outputting the dependency information for building a project.\nThe value of this variable is typically handled by qmake or qmake.conf\nand rarely needs to be modified.\n\nI annotated the src.pro file and I found that line belongs from the\nvery first version of src.pro, possibly copied from the Qt examples,\nso it smells you are right and we could remove that.\n\nMarco\n"},{"id":"87554","messageId":"20080818180048.GA15520@efreet.light.src","threadId":"14897","inReplyTo":"e5bfff550808171330w28dda6a2m32b0e51b1ef73cdc@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-18T18:00:48Z","receivedAt":"2008-08-18T18:00:48Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Aug 17, 2008 at 21:30:46 +0100, Marco Costalba wrote:\n> On Sun, Aug 17, 2008 at 8:58 PM, Jan Hudec wrote:\n> >\n> > But as I said, I only have basic infrastructure and am currently looking at\n> > what to write tests for and how exactly that test should work. The detection\n> > of git vs. stgit branch (does not work for me)\n> \n> This sounds as a bug. Could you elaborate on that please ?\n> \n> \n> BTW the test for a StGit repo is:\n> \n> isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n> \n> in function Git::getRefs() , file git_startup.cpp\n\nYes, I've seen that command. But it returns true for me even when it's not\na stg branch :-(. I am not sure what the problem there is.\n\n> > Well, I somehow managed -- except I am not sure I dealed with the windows\n> > part correctly. What could be improved is maybe if you know how to signal\n> > a dependency between two projects. I currently rely on the top-level makefile\n> > always calling the subdirs in the order they are specified, but I fear\n> > portable recursive make does not really offer any better solution, so qmake\n> > can't really do that either.\n> >\n> \n> Could the following help ?\n> \n> http://lists.trolltech.com/qt4-preview-feedback/2004-10/thread00174-0.html\n\nDoes help a bit. Thanks.\nThat is, confirms my suspicion that there is no really correct solution and\nremembered me the ordered config option, that I noticed in the documentation\nonce, but wasn't able to find again when I actually wrote the .pro files.\n\nAdded the option and rewound the branch on repo.or.cz.\n\n> > Note: I think I found a bug in qmake here -- when you run qmake at top level,\n> > the makefile will call qmake in subdirectories to create makefiles there, but\n> > the rule has no dependencies, so it will not remake the makefiles when the\n> > .pro files change there.\n> >\n> \n> I knew that. For my use I always delete Makefiles after modifying any\n> of *.pro files, I'm sure it exists a better way but honestly I didn't\n> investigate too much on this.\n\nI don't think there's too much to investigate -- it looks like an obvious bug\n;-). Unless it's caused by the MAKEFILE setting :-( (I'll have to remove it\nand check)\n\n> > Also I don't understand why you set 'MAKEFILE = qmake' in the src/src.pro --\n> > it does not seem to be respected, at least when I call it through the\n> > top-level qgit.pro (which I now have to when there are 3 subdirs).\n> >\n> \n> >From http://doc.trolltech.com/4.0/qmake-variable-reference.html#makefile\n> \n> MAKEFILE\n> This variable specifies the name of the Makefile which qmake should\n> use when outputting the dependency information for building a project.\n> The value of this variable is typically handled by qmake or qmake.conf\n> and rarely needs to be modified.\n> \n> I annotated the src.pro file and I found that line belongs from the\n> very first version of src.pro, possibly copied from the Qt examples,\n> so it smells you are right and we could remove that.\n\nLooks like that. Funny thing is, that normally the makefiles are called\nMakefile for me, not qmake, but I did see the qmake files (IIRC when I ran\nqmake -recursive). That would mean it takes the value from the top-level .pro\nand ignores it in the subdirs.\n\nRegards,\nJan\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"87702","messageId":"e5bfff550808190753t4f99ddb6q83886dbca27dbf03@mail.gmail.com","threadId":"14897","inReplyTo":"20080818180048.GA15520@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-19T14:53:05Z","receivedAt":"2008-08-19T14:53:05Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Mon, Aug 18, 2008 at 7:00 PM, Jan Hudec wrote:\n> On Sun, Aug 17, 2008 at 21:30:46 +0100, Marco Costalba wrote:\n>> On Sun, Aug 17, 2008 at 8:58 PM, Jan Hudec wrote:\n>> >\n>> > But as I said, I only have basic infrastructure and am currently looking at\n>> > what to write tests for and how exactly that test should work. The detection\n>> > of git vs. stgit branch (does not work for me)\n>>\n>> This sounds as a bug. Could you elaborate on that please ?\n>>\n>>\n>> BTW the test for a StGit repo is:\n>>\n>> isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n>>\n>> in function Git::getRefs() , file git_startup.cpp\n>\n> Yes, I've seen that command. But it returns true for me even when it's not\n> a stg branch :-(. I am not sure what the problem there is.\n>\n\nThat's interesting !\n\nThe command just runs \"stg branch\", in my StGit setup this returns an\nerror (some stuff written to stderr) if the directory where it is run\nis not a StGit stack.\n\nrun() just detects the error and returns false.\n\nCould you try to run it from a console and see if you have stuff on stderr ?\n\nThanks\nMarco\n"},{"id":"88772","messageId":"20080827201819.GD15520@efreet.light.src","threadId":"14897","inReplyTo":"e5bfff550808190753t4f99ddb6q83886dbca27dbf03@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-27T20:18:19Z","receivedAt":"2008-08-27T20:18:19Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Aug 19, 2008 at 15:53:05 +0100, Marco Costalba wrote:\n> On Mon, Aug 18, 2008 at 7:00 PM, Jan Hudec wrote:\n> > On Sun, Aug 17, 2008 at 21:30:46 +0100, Marco Costalba wrote:\n> >> On Sun, Aug 17, 2008 at 8:58 PM, Jan Hudec wrote:\n> >> >\n> >> > But as I said, I only have basic infrastructure and am currently looking at\n> >> > what to write tests for and how exactly that test should work. The detection\n> >> > of git vs. stgit branch (does not work for me)\n> >>\n> >> This sounds as a bug. Could you elaborate on that please ?\n\nI am slowly progressing towards writing a test case for it ;-).\n\nActually, I just wrote a first simple test for it. I didn't find this (now\nthe stg branch finds out properly), but I found another problem -- when\nswitching from non-stgit branch to a stgit one, Git::init will not notice,\nbecause the path didn't change, so the check is not re-run. Applies to the\nother direction too, of course.\n\n> >> BTW the test for a StGit repo is:\n> >>\n> >> isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n> >>\n> >> in function Git::getRefs() , file git_startup.cpp\n> >\n> > Yes, I've seen that command. But it returns true for me even when it's not\n> > a stg branch :-(. I am not sure what the problem there is.\n> >\n> \n> That's interesting !\n> \n> The command just runs \"stg branch\", in my StGit setup this returns an\n> error (some stuff written to stderr) if the directory where it is run\n> is not a StGit stack.\n\nI don't recall the details (it was some time ago) and the repository might\nhave been a bit screwed up. The point there was the branch /used to be/\na stgit one. So it was rather a problem of stgit keeping duplicate\ninformation all over the place.\n\n> run() just detects the error and returns false.\n\nBy the way, I looked at the makefiles again and found that they are actually\nregenerated correctly when you change the .pro files. While the master\nmakefile does not have dependencies for the subdir makefiles, each makefile\ndoes have dependencies for itself. And make always tries to rebuild the\nmakefile before doing anything else. Therefore it does not work to:\n make src//Makefile\nbut it *does* work to:\n make -C src Makefile\n(*and* it will rebuild the makefile when you 'make debug' or 'make release').\n\nRegards,\nJan\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"89009","messageId":"e5bfff550808280429h63496f9byfa4454af7adb0e86@mail.gmail.com","threadId":"14897","inReplyTo":"20080827201819.GD15520@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-28T11:29:25Z","receivedAt":"2008-08-28T11:29:25Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Wed, Aug 27, 2008 at 10:18 PM, Jan Hudec wrote:\n>\n> Actually, I just wrote a first simple test for it. I didn't find this (now\n> the stg branch finds out properly), but I found another problem -- when\n> switching from non-stgit branch to a stgit one, Git::init will not notice,\n> because the path didn't change, so the check is not re-run. Applies to the\n> other direction too, of course.\n>\n\nI have never tested on repos where some branches are under stgit and\nothers are not. Actually I even didn't know it was possible.\n\nThe command:\n\nisStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n\nis used to check if a repo is under StGit control, i.e 'stg init' has\nbeen run in the repo working directory (it doesn't mean that there are\nStGit patches applied or unapplied, could be also without them).\n\nSo It's not very clear to me what does it mean \"switching from\nnon-stgit branch to a stgit one\"\n\nThanks\nMarco\n"},{"id":"88898","messageId":"20080828153118.GA13169@diana.vm.bytemark.co.uk","threadId":"14897","inReplyTo":"e5bfff550808280429h63496f9byfa4454af7adb0e86@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-08-28T15:31:18Z","receivedAt":"2008-08-28T15:31:18Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-08-28 13:29:25 +0200, Marco Costalba wrote:\n\n> On Wed, Aug 27, 2008 at 10:18 PM, Jan Hudec wrote:\n>\n> > Actually, I just wrote a first simple test for it. I didn't find\n> > this (now the stg branch finds out properly), but I found another\n> > problem -- when switching from non-stgit branch to a stgit one,\n> > Git::init will not notice, because the path didn't change, so the\n> > check is not re-run. Applies to the other direction too, of\n> > course.\n>\n> I have never tested on repos where some branches are under stgit and\n> others are not. Actually I even didn't know it was possible.\n\nStGit has no per-repo data. It's all per-branch. \"stg init\" operates\non the current branch, not the whole repo.\n\n> The command:\n>\n> isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n>\n> is used to check if a repo is under StGit control, i.e 'stg init'\n> has been run in the repo working directory (it doesn't mean that\n> there are StGit patches applied or unapplied, could be also without\n> them).\n\nHmm. For me, \"stg branch\" succeeds even if \"stg init\" has not yet been\nrun (which is arguably as it should be, since it doesn't require that\nstg init has been run in the current branch). \"stg series\" or\nsomething is probably better for this purpose.\n\nThough if you're concerned about speed (as the comment indicates), you\nshould probably do something cheaper than running stg, such as\nchecking if .git/patches/ exists.\n\n> So it's not very clear to me what does it mean \"switching from\n> non-stgit branch to a stgit one\"\n\nSwitching from a branch where \"stg init\" hasn't been run, to one where\nit has.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"88946","messageId":"e5bfff550808281154h67392297y3a08d4ed8aea408f@mail.gmail.com","threadId":"14897","inReplyTo":"20080828153118.GA13169@diana.vm.bytemark.co.uk","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-28T18:54:44Z","receivedAt":"2008-08-28T18:54:44Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Thu, Aug 28, 2008 at 5:31 PM, Karl Hasselström wrote:\n>\n> StGit has no per-repo data. It's all per-branch. \"stg init\" operates\n> on the current branch, not the whole repo.\n>\n\nOk. Thanks. In this case the check qgit does is broken, and I think\nnot only that because I never had this point clear while developing\nthe interface.\n\n>\n> Hmm. For me, \"stg branch\" succeeds even if \"stg init\" has not yet been\n> run (which is arguably as it should be, since it doesn't require that\n> stg init has been run in the current branch). \"stg series\" or\n> something is probably better for this purpose.\n>\n\nBut if I run 'stg branch' in a git-only repo this gives an error. This\nconditions, at least until now, has always been working for me.\n\n\n> Though if you're concerned about speed (as the comment indicates), you\n> should probably do something cheaper than running stg, such as\n> checking if .git/patches/ exists.\n>\n\nActually the actual code chunk is:\n\n // check for a StGIT stack\n QDir d = gitDir;\n\n if (d.exists(\"patches\")) { // early skip\n\n isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n\n stgCurBranch = stgCurBranch.trimmed();\n } else\n isStGIT = false;\n\n\n\nIndeed I need the Stgit current branch name to filter out the refs\nfound with a following \"git show-ref -d\" command:\n\nThe code chunk is actually\n\n// run the command and save output in runOutpt\nif (!run(\"git show-ref -d\", &runOutput))\n return false;\n\nQStringList refsList = runOutput.split('\\n', QString::SkipEmptyParts);\n\nFOREACH_SL (it, refsList) {\n\n QString revSha = (*it).left(40);\n QString refName = (*it).mid(41);\n\n // save StGIT patch sha, to be used later\n if (refName.startsWith(\"refs/patches/\" + stgCurBranch + \"/\")) {\n\n .... we have found a reference to a StGit patch of\ncurrent branch ...\n }\n\n......\n\n}\n\n\n\n>> So it's not very clear to me what does it mean \"switching from\n>> non-stgit branch to a stgit one\"\n>\n> Switching from a branch where \"stg init\" hasn't been run, to one where\n> it has.\n>\n\nThanks again. I don't know why but I was somehow sticked to the idea\nthat 'stg init' was behaving similar to 'git init', i.e. you need to\nrun it only once per repo.\n\nMarco\n"},{"id":"89023","messageId":"20080828220124.GF15520@efreet.light.src","threadId":"14897","inReplyTo":"e5bfff550808281154h67392297y3a08d4ed8aea408f@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-28T22:01:24Z","receivedAt":"2008-08-28T22:01:24Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Aug 28, 2008 at 20:54:44 +0200, Marco Costalba wrote:\n> On Thu, Aug 28, 2008 at 5:31 PM, Karl Hasselström wrote:\n> > StGit has no per-repo data. It's all per-branch. \"stg init\" operates\n> > on the current branch, not the whole repo.\n> \n> Ok. Thanks. In this case the check qgit does is broken, and I think\n> not only that because I never had this point clear while developing\n> the interface.\n> \n> > Hmm. For me, \"stg branch\" succeeds even if \"stg init\" has not yet been\n> > run (which is arguably as it should be, since it doesn't require that\n> > stg init has been run in the current branch). \"stg series\" or\n> > something is probably better for this purpose.\n\nThat would indeed mean, that the check does not do what indented and would\nshow the same symptoms I recalled initially. Seems I can finally reproduce\nthem.\n\n> But if I run 'stg branch' in a git-only repo this gives an error. This\n> conditions, at least until now, has always been working for me.\n> \n> \n> > Though if you're concerned about speed (as the comment indicates), you\n> > should probably do something cheaper than running stg, such as\n> > checking if .git/patches/ exists.\n> >\n> \n> Actually the actual code chunk is:\n> \n> // check for a StGIT stack\n> QDir d = gitDir;\n> \n> if (d.exists(\"patches\")) { // early skip\n> \n> isStGIT = run(\"stg branch\", &stgCurBranch); // slow command\n> \n> stgCurBranch = stgCurBranch.trimmed();\n> } else\n> isStGIT = false;\n\nOok. Ook.\n\nNow I actually wrote the test cases I am begining to understand why it\nbehaves the way it does. \n\nSo, now there is a test infrastructure plus test case to reproduce this\nswitching between stgit and non-stgit branch in\ngit://repo.or.cz/qgit4/bulb.git (http://repo.or.cz/r/qgit4/bulb.git) with\nwhoping 9 commits. Should I send out a patch series, or do you prefer just\npulling?\n\nNow in my opinion the code could use some refactoring rather than just fixing\nthe bugs (my long term intent is to add features like topgit support,\npush/pull/merge and other things git-gui can do and such). I'd start with\nthe Git initialization sequence. I'll write tests for the new code, but as\nI expect it to have significantly different interface from the old one, I'll\nnot try to write tests for the current one.\n\nBest regards,\nJan\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"89020","messageId":"20080828221822.GA21850@diana.vm.bytemark.co.uk","threadId":"14897","inReplyTo":"e5bfff550808281154h67392297y3a08d4ed8aea408f@mail.gmail.com","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-08-28T22:18:22Z","receivedAt":"2008-08-28T22:18:22Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-08-28 20:54:44 +0200, Marco Costalba wrote:\n\n> On Thu, Aug 28, 2008 at 5:31 PM, Karl Hasselström \n> wrote:\n>\n> > StGit has no per-repo data. It's all per-branch. \"stg init\"\n> > operates on the current branch, not the whole repo.\n>\n> Ok. Thanks. In this case the check qgit does is broken, and I think\n> not only that because I never had this point clear while developing\n> the interface.\n>\n> > Hmm. For me, \"stg branch\" succeeds even if \"stg init\" has not yet\n> > been run (which is arguably as it should be, since it doesn't\n> > require that stg init has been run in the current branch). \"stg\n> > series\" or something is probably better for this purpose.\n>\n> But if I run 'stg branch' in a git-only repo this gives an error.\n> This conditions, at least until now, has always been working for me.\n\nAh. I guess it might have gotten fixed recently, then. [ ... makes\nsome quick tests ... ] Yes, it gives an error in 0.13, but not in\n0.14.\n\nNot failing in this case is arguably correct for stg branch. But stg\nseries can per definition not work before stg init, so I recommend you\nuse that instead. Or don't use an stg command at all.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"89093","messageId":"e5bfff550808290001r168c7edfre926f1bc735f3ad0@mail.gmail.com","threadId":"14897","inReplyTo":"20080828220124.GF15520@efreet.light.src","subject":"Re: [QGIT RFC] Unit tests for QGit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-08-29T07:01:48Z","receivedAt":"2008-08-29T07:01:48Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Fri, Aug 29, 2008 at 12:01 AM, Jan Hudec wrote:\n>\n> So, now there is a test infrastructure plus test case to reproduce this\n> switching between stgit and non-stgit branch in\n> git://repo.or.cz/qgit4/bulb.git (http://repo.or.cz/r/qgit4/bulb.git) with\n> whoping 9 commits. Should I send out a patch series, or do you prefer just\n> pulling?\n>\n\nI prefer to pull.\n\n> Now in my opinion the code could use some refactoring rather than just fixing\n> the bugs (my long term intent is to add features like topgit support,\n> push/pull/merge and other things git-gui can do and such). I'd start with\n> the Git initialization sequence. I'll write tests for the new code, but as\n> I expect it to have significantly different interface from the old one, I'll\n> not try to write tests for the current one.\n>\n\nWe have following possibilities:\n\n- Pull the code directly in qgit master as soon as there are some new\ncommits in your branch\n\n- Pull the code in public qgit repo but under a different branch,\nlet's call' it \"next\" ;-)\n\n- Waiting for your code has stabilized a bit (testing infrastructure\nis very young and for what I have seen from revision history code is\nstill very 'fluid'), then pull the branch in qgit master directly.\n\n\nThese are my two cents:\n\nOption one could be a little bit misleading for people pulling from\nqgit repo to get current qgit sources + just fixes.\n\nOption two is doable but is an additional step with an additional\nmaintainer burden, probably the current number of contributors to qgit\nis not enough to justify such a complex development model.\n\nPerhaps option three it seems the more balanced, also looking at\nprojects git related and with similar size of qgit, as example StGit\nitself. When let's say Karl has ready a block of patches he sends them\nall as a series and are applied to StGit master branch.\n\nThe only modification I would suggest is that I can pull from you repo\ndirectly instead of asking you to send patches to the git list.\n\nI leave up to you when to ask for a pull request, I only ask you to\nconsider that qgit public repo is pulled also by people not interested\nin the latest development, and they only want a stable qgit, so please\nask for a pull when you think stuff is stable enough.\n\nComments?\n\nMarco\n"}]}