couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Git Repository Creation
Date Tue, 21 Jan 2014 10:45:14 GMT
On Tue, Jan 21, 2014 at 10:19 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Tue, Jan 21, 2014 at 12:32 AM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> > On Sat, Jan 18, 2014 at 2:10 AM, Paul Davis <paul.joseph.davis@gmail.com
> >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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message