[rspec-devel] Back to one repository?

[Jake Howerton]

Thought I could chime in on how I am managing embedded repositories on
git right now.  I mentioned braid before and this is the main tool I
am using. I have 2 projects that share some code that I keep in a
'shared' repo. If the project necessitates that changes be made to the
shared code I make the changes in my branch of the current project,
finish my changes, and merge that branch into master for that project.
 I then generate a patch for the shared lib and apply it to that repo.

Here is how the flow might look if you are working on rspec this way:

Say you have ~/rspec-work and rspec-dev, rspec, and rspec-rails repos
are below this. I am going to assume braid is setup to track
everything for the time being. You would do your work in rspec-dev.

cd ~/rspec-work/rspec-dev
git checkout -b new-feature
.... do work and find it necessary to change shared dir
... run pre_commit and merge your changes into master
# generate a patch to go to rspec repo
git braid-diff lib/rspec > ~/rspec-work/rspec/my-change.patch
cd ~/rspec-work/rspec
patch -p3 < my-change.patch  (not sure what the p level would actually be)
rm my-change.patch
git commit -a -m 'commit new feature from rspec-dev'

Then push changes in rspec to github, switch back to rspec-dev and
update your braid/track branch, rinse, repeat.

braid-diff is an alias I have:
braid-diff = diff braid/track master --


I don't know if this seems convoluted but it is really simple once you
make it a habit and it could probably be a little more automated.

-Jake

On Fri, Apr 18, 2008 at 9:05 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On Fri, Apr 18, 2008 at 6:27 PM, Pat Maddox <pergesu at gmail.com> wrote:
>  > Brian, Alex Chaffee and I were talking about the repository layout
>  >  just now.  Alex pointed out that there's a lot of overhead when using
>  >  the rspec project... I've written a bunch of rake tasks to reduce
>  >  that, but even with those there's overhead.  And as we figure out more
>  >  tasks, we'll have to write more rake tasks to automate some of the
>  >  stuff.  For example, if you git:pull and there's a conflict, you have
>  >  to go resolve the conflict and continue the rebase.  Does it make
>  >  sense to write a git:continue command that will examine any repos that
>  >  had a conflict and are in need of a rebase continue?  I'm not sure at
>  >  this point, but it's one of many potential questions.
>  >
>  >  Alex suggested that we go back to one repository, and change the
>  >  plugin installation process.  Basically the only reason the repos are
>  >  split right now is because there's no way to check out directories,
>  >  and we want people to easily install the rspec and rspec-rails
>  >  plugins.
>  >
>  >  What if instead of separate repos, we had people put the entire
>  >  codebase under vendor/rspec?  Then they could run a script like
>  >  vendor/rspec/install_plugins that would export the rspec and
>  >  rspec-rails dirs to vendor/plugins.
>  >
>  >  I realize there will probably be some apprehension given that David
>  >  did a lot of work to split the repos in the first place, and the
>  >  headaches over the past couple days, but I think it's a very good idea
>  >  that's worth considering.  If nothing else, we should keep it in mind
>  >  over the next couple weeks, and see what growing pains we experience
>  >  that might be avoided by a unified repo.
>
>  The work that I've done (and that you've done, Pat) should not be a
>  consideration. If there is a better way, we should pursue it.
>
>  I have a lot of thoughts about this but no time to present them right
>  now. I'll follow up over the weekend.
>
>  David
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>