On Tue, Jan 21, 2014 at 10:19 AM, Paul Davis <[email protected]>wrote:
> On Tue, Jan 21, 2014 at 12:32 AM, Benoit Chesneau <[email protected]> > wrote: > > On Sat, Jan 18, 2014 at 2:10 AM, Paul Davis <[email protected] > >wrote: > > > >> I've spent most of the day initializing all of our new repositories > >> with the source code for each Erlang application. I've taken special > >> care to make sure that we're retaining as much history as possible. > >> I'm pretty sure that most apps are correct but we'll want to do some > >> auditing in the future before we flip the switch in the future. > >> > >> The code versions are generally speaking either what's on master or on > >> the 1843-feature-bigcouch branch. A few of them I pulled out of the > >> 1994-merge-rcouch branch or from their respective external > >> repositories in the case of ibrowse, mochiweb, and jiffy. > >> > >> Its important to note that all code was imported using a branch named > >> "import" so that we can spend time reviewing code and possibly > >> rewriting history before we commit to what the initial value for each > >> repo should be. If you clone any of these repos git will be a bit > >> confused until you switch to that branch. > >> > >> The couchdb-couch repo is actually a combination of what's on > >> 1843-feature-bigcouch but is rebased against the current master so it > >> should be all the things from both of those. I haven't investigated > >> how much 1994-merge-rcouch has changed actual underlying code as > >> opposed to just moved source code around so we'll have to coordinate > >> there. > >> > >> We'll get the 1843-feature-bigcouch branch updated in the near future > >> to start pulling each of these repositories directly so that people > >> can see how that works in practice. > >> > >> Also of note there are currently three repos that are still empty. The > >> couchdb-couch-collate.git, couchdb-fauxton.git, and > >> couchdb-documentation.git are all uninitialized. For fauxton and > >> documentation I want to hear from people that are more involved with > >> what they'd want in there. I'm not familiar enough to be confident > >> that I've not screwed anything up for either of those. I didn't need > >> couch-collate but I'll get to that soonish. > >> > >> The other thing to point out is that Adam created a ticket in the > >> middle of the email storm that people may want to chime in on to > >> discuss the new commit email subject lines: > >> > >> https://issues.apache.org/jira/browse/COUCHDB-2032 > >> > > > > Hi Paul, > > > > I took the time time to look at the created repostories and wanted to put > > some work from the rcouch branch merge branch but not sure how to do it > > right now. > > > > For example the couch, couch_replicator branches are conflicting right > now. > > The couch_mview will conflict soon. Little detail but imo rather than > > imported the specific bigcouch branch should have been named > > "bigcouch-import". Anyway that's a detail. Anyway I am thinking to create > > an rcouch-import branch . Is this what you were thinking about? > > > > About the mochiweb, ibrowse and other dependencies branches, maybe we > could > > update them with the currrenr upstream and merge really little changes > we > > still have in our repo. While we are here submit these little changes to > > upstream as patches. It would be extremely useful in the case of mochiweb > > so we can add easily the websocket support to _changes. For ibrowse most > > have alreadybeen merged upstream, except this latest socks5 patch. > > erlangoauth from upstream has also some changes to support latest Erlang > > that we probably need. > > > > Let me know, > > > > - benoit > > Awesome, thanks for checking things out. My initial pass at this was > mostly to make sure I knew how to extract each repository while > maintaining the correct history in the new repositories as close as > possible. Redoing things isn't a huge deal as most of it was just > checking to make sure I knew how to use git subtree and friends to do > history extraction. > > As to bigcouch/rcouch conflicts its something we'll need to figure out > for sure. I don't really see much point in trying to create > bigcouch/rcouch specific branches for the initial import though. I did > include bigcouch merge related patches on both of couch and > couch_replicator cause I was worried about the history extraction. > > The "proper" approach I think is to go back and reset each repo to the > equivalent commit pointed at by the merge-rebase-target tag and then > we should create branches 1843-feature-bigcouch and 1994-merge-rcouch > branches in each repo where we have conflicts. Once that's done we can > focus on the actual conflicts to see where we need to work on merging > actual code changes. The important part here is to have a common > history for each sub-repo we agree on that is the initial import and > then we can focus on the merge work at hand. > > For the upstream repos I need to add some more work to those to > reflect changes that we've made since march of this year when we > started the bigcouch merge. I definitely agree that we should be > pushing our changes upstream so that these are as close to raw mirrors > as possible. The ibrowse and mochiweb branches were direct from > upstream repos and I think I pulled oauth from the rcouch repo. The > mochiweb commit was super old but ibrowse was relatively close. I know > we've changed things here recently and we'll want to get as much of > that upstream as possible. > > I'm going to be digging back into this work at the end of the week or > early next week. Let me know if you find anything else that needs to > be addressed. > OK I see, thanks for the answer. I will wait a little then before moving the code, except maybe for the external dependencies then :) I opened another thread about the merge. Maybe it will help us to start the work and ease each merges. benoit - benoit
