From: Grant I. <gsi...@ap...> - 2008-08-04 16:29:43
|
What's so hard about a patch: svn diff > ../mypatch.patch When patch is reviewed: svn ci -m "PATCH XXX applied." ... -Grant On Aug 4, 2008, at 5:07 AM, Leo Sauermann wrote: > Hi Guys, > > as said in the other mail, I would *not* change our code management > rules now. > > to give more arguments and discuss this further: > Also, I don't like the patch-idea because it is NOT convenient at all. > I prefer branches and merging them back quickly once the tests pass > (like, a branch exists for a week or two). > > As you can easily see when reading Antoni's step-by-step > instructions below, applying patches SUCKs > comared to > Generating a branch > 1. "right clikc on the project -> team -> create branch" > 2. commit - done > Applying a branch > 1. "right clikc on the project -> team -> switch to branch/tag" -. > done > > roughly 3 actions compared to 23 and all within the same application > (no filesystem, no sourceforge website needed, no possiblity > whatsoever to fuck up) > > > So IF we need the policy of "the trunk must always work and all > tests pass" THEN we could think about switching, and THEN we can > chose between diff-or-branch based management. > We *must* think about it WHEN going the maven way/continous build/ > nightly integration. > > best > Leo > > > > It was Antoni Mylka who said at the right time 01.08.2008 21:36 the > following words: >> >> Just to let you know. I've reverted the revision 1377. The trunk is >> as stable as it was before. I'm investigating ways to make the >> patch-commit setup as painless as possible. Right now the workflow >> would be >> >> Generating a patch >> 1. right click on the project -> team -> create patch >> 2. click save in the filesystem >> 3. type the name >> 4. click next >> 5. click generate >> 6. log in to sourceforge >> 7. navigate to the corresponding issue >> 8. scroll down to see the field with "Add attachment" >> 9. click "browse" >> 10. find your patch in the correct folder >> 11. upload it to the issue >> >> Applying >> 1. get to know that there is a patch worth reviewing >> 2. navigate to the corresponding issue >> 3. scroll down to the attachments >> 4. right click the attachment and go to Save file as >> 5. save the file in a known folder >> 6. in eclipse right click on the project and go to team apply patch >> 7. click file >> 8. click browse >> 9. find the file in the browse window and click ok >> 10. click next >> 11. click next once more (resolve conflicts) >> 12. click finish >> >> Grant, is that the way you work? >> >> My dream would be a tool integrated with eclipse that would do >> 1. right click on a project with patches >> 2. choose submit a patch to sourceforge (the plugin remembers the >> sourceforge project associated with an eclipse workspace project, >> and the sourceforge credentials) >> 3. it shows a jtree with trackers on the first level, and open >> issues on the second level - >> 4. i choose an issue and click ok, it automatically generates a >> diff, names it <issue-id>-<current_working_copy_revision>.diff and >> submits it to sourceforge >> >> likewise when applying a patch >> 1. right click on a project >> 2. choose apply a patch from sourceforge >> 3. it shows a jtree with trackers on the first level, open issues >> on the second level and attachments ending with .diff on the third >> level >> 4. i choose a patch, click ok, it automatically downloads the diff >> and applies it >> >> what's your workflow? I hope it's simpler. I'm afraid it will be >> hard to convince the Aperture community to adopt the first process. >> >> -- >> Antoni Myłka >> ant...@gm... >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in >> the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> _______________________________________________ >> Aperture-devel mailing list >> Ape...@li... >> https://lists.sourceforge.net/lists/listinfo/aperture-devel >> > > > -- > ____________________________________________________ > DI Leo Sauermann http://www.dfki.de/~sauermann > > Deutsches Forschungszentrum fuer > Kuenstliche Intelligenz DFKI GmbH > Trippstadter Strasse 122 > P.O. Box 2080 Fon: +49 631 20575-116 > D-67663 Kaiserslautern Fax: +49 631 20575-102 > Germany Mail: leo...@df... > > Geschaeftsfuehrung: > Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > Amtsgericht Kaiserslautern, HRB 2313 > ____________________________________________________ > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel -------------------------- Grant Ingersoll http://www.lucidimagination.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ |