On Mon, Dec 27, 2010 at 5:35 PM, Paul Davis <[email protected]> wrote: > On Mon, Dec 27, 2010 at 7:23 AM, Benoit Chesneau <[email protected]> wrote: >> On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis <[email protected]> >> wrote: >>> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <[email protected]> >>> wrote: >>>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis >>>> <[email protected]> wrote: >>>> >>>>> >>>>> Its not being done in trunk. The change is being prepared as a script >>>>> and set of patches that people can test independently which people >>>>> have been doing. >>>>> >>>> Not what I say. Was about testing it first in it's own branch. But >>>> right patches are enough. Just actually i'm not sure how i can edit >>>> one or go further ? Another patch ? What's your process to make such >>>> patches at first ? stashes ? >>>> >>> >>> I use the generated git repo to formulate all of the various patches. >>> There are git-save and git-restore commands for the srcmv.py script >>> that work as expected by saving patches to the couchdb.patches >>> directory. >>> >> Will try to work with that then. >> >>> This is a scenario that is so distant I'm not going to spend time >>> thinking about it right now. The current work would in no way allow >>> for someone to do such things and it will be many many months before >>> we have things to a point before we can entertain such notions. >>> >> >> It could be months or days. Depends on the the time each others can >> put in it, *if the process allows it*. This is imo a big priority, we >> already see a lot of "bricolage" (makeshift?) coming in the code. >> >> The goal I wished in the thread I launched was to use rebar and mix it >> with configure (based on bigcouch work and patches like these one). I >> don't see how the question is so distant seeing the result of these >> patches. Neither I see why we shouldn't target this right now. Anyway, >> maybe we can open a ticket and track progress in it ? > > I'm so confused. What process are you talking about? What breakage (I > assume that's what you mean) do you see coming?
I'm speaking about a way to work with such changes. Patches are good, but in the mean time vcs are here for a reason. A quick way to test/merge etc. I'm just looking for a way to work with the patch between different person. Trying to find a way to make the process easy. > > You're describing two entirely different, completely unrelated use > cases for rebar. One, which was part of the motivation for this patch > set, was to integrate it into the build system. This is perfectly > acceptable. It is why this patch set exists; to make using rebar to > build CouchDB *possible*. After this very large patch set is committed > then we can start working on supporting rebar. > Well I don't describe unrelated use, just describing what I wished, and started thread, that wasn't closed nor really discussed. Now I understand that the patches won't go as far as I would like. > The situation you described earlier is a bajillion percent different. > Perhaps in a distant future we will support using only various parts > of CouchDB but this is a scenario so far distant that I am not going > to spend any time considering it. > I understand that.
