hi, what is the best procedure to produce patches for subversion-1.7.0-alpha2. some of the old ones are not applying cleanly? i saw http://wiki.opencsw.org/using-git-to-produce-patches.
rupert. On Thu, Jan 6, 2011 at 02:30, Ben Walton <[email protected]> wrote: > Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011: > > Hi Rupert, > > I'm sorry this wasn't easier for you. > > > * try to build, not all patches applied > > * throw away the old patches, check in > > First, a recommendation: Never throw away patch/script/foo files from > an existing build until you've got a working replacement. I've kicked > myself a few times for doing this. :) > > In a situation like this, I'd see if I could get the patches to apply > manually using patch or other methods. > > > * "gmake extract" to get the source back > > * edit the files again like it should be > > Although it may not complain, makepatch would prefer to be called > after `gmake patch` to ensure all existing patches are applied. I > forget whether I enforced this with a constraint or not...If not, I > don't recall a the reason why I didn't. > > > * "gmake makepatch" > > * "gmake package", failed as there is a new file which would need > > patching as well. > > > * "gmake clean", "gmake extract" again > > * edit the file > > * "gmake makepatch" again > > Did you see your first patch applied in this process at all? If not, > you're working on a pre-patched set of files. > > > then i forgot to delete a line in a file which is already patched, and > > i thought about repeating above procedure again: > > 1. gmake extract > > applied patch 001 > > 2. gmake makepatch > > tried to apply patch 001 again > > which failed. > > This is likely due to creating a patch against the unpatched tree > above. If so, I should look at making sure makepatch cannot run > unless the patch target has already been called. You could, > potentially still have problems though... > > > then i gave up for the moment ... but this cannot be it, isn't it? > > should we switch to the whole source from subversion to git and it > > would be neater? then patches could be rebased instead of applied > > newly. > > I wouldn't object[1], but others may disagree. It's also a huge > undertaking. I know that many others are also using git quite a bit > lately too. > > The first major portion of this transition would require separating > GAR (the tool) from the build recipes. Git simply doesn't handle > (nicely) the idea of an external like subversion does. This would be > the final impetus to separate the two, most likely using Sebastian's > excellent mgar! > > I know that Maciej has been having both success and frustration using > the git-svn bridge as of late... > > Thanks > -Ben > > [1] It would actually make my day! > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > [email protected] > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. >
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
