[rspec-devel] Back to one repository?
jake.howerton at gmail.com
Sat Apr 19 02:01:50 EDT 2008
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.
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
patch -p3 < my-change.patch (not sure what the p level would actually be)
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.
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.
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel