[rspec-users] OT local version control?

Corey Haines coreyhaines at gmail.com
Mon Feb 4 19:33:32 EST 2008

Thanks for the response, Luis.

I'm going through the user manual, and it looks like I can set up a main
branch, make a clone, work on the clone with its own repository/revisions,
then merge the changes back to the main branch when I'm ready. I like the
idea of being able to work on several things at once. I'll let you guys know
how it goes.


On Feb 4, 2008 7:09 PM, Luis Lavena <luislavena at gmail.com> wrote:

> On Feb 4, 2008 9:28 PM, Corey Haines <coreyhaines at gmail.com> wrote:
> > Since it sounds like people don't mind talking about source control, and
> > this group has people I trust, I thought, as I went through the
> > learning/evaluating, I'd ask questions/make statements and get people's
> > thoughts. If people on the list get annoyed, though, just let me know
> > (offgroup is fine), and I'll stop the distractions, unoffended.
> At least this group didn't react like others with "X is better than
> anything else..."
> I think David Chelimsky personally uses git for rspec, but being a
> nice guy, pushes svn mirrors for it.
> > Question/Discussion 1
> > Coming from an old school source control world, I'm used to the idea of
> > "check out some files, work on them, check them back in." It seems like
> > systems, at level 1, is "make a copy of your project, edit the files to
> make
> > the change, then merge it back into your main branch." I see a lot
> > discussion with pictures about it really more like a bunch of
> > copies/branches of one project, moving through time independently, the
> > merging back at some future date. I'm having a bit of trouble in my mind
> > with this, so I'll leave that to the next level.
> Yeah, can be tricky sometimes, the learning curve can be steep, but is
> worth.
> When you checkout using a DVCS, you're not actually getting just a
> working copy, but the whole repository history.
> In that way, you can get differences, compare, list the log messages,
> everything without a single hit to the server (tried do a blame with
> svn?)
> The idea of branching is that you can implement new features "outside"
> trunk and don't affect the code stability.
> I've been using Bzr not just for personal projects, but also to track
> changes and submit patches to other open source projects, just to
> mention:
> ruby (1.8 and 1.9)
> mongrel
> hoe
> rubygems
> rubyinline
> parsetree
> rspec (even with the small contribution I did)
> Since for most of these projects I don't have commits rights, and some
> of them I don't even have access to the code (inline, hoe and
> parsetree).
> I create a "branch" for things, and do small commits based on the
> changes I've introduced, but that will depend on the workflow you're
> used.
> Later, when that feature is ready for integration, you then prepare
> and merge upstream with it.
> Takes some time to get used to it ;-)
> Anyway, at least with bzr, you can work in a similar way to subversion
> (running a smart server) and have bound checkout.
> In any case, read the documentation of all the dvcs to find the one
> that fits your current workflow but will allow improve it with time.
> HTH,
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080204/c90679e4/attachment.html 

More information about the rspec-users mailing list