couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Git Repository Creation
Date Tue, 21 Jan 2014 09:19:49 GMT
On Tue, Jan 21, 2014 at 12:32 AM, Benoit Chesneau <> wrote:
> On Sat, Jan 18, 2014 at 2:10 AM, Paul Davis <>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:
> 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.

View raw message