On Feb 4, 2008 9:28 PM, Corey Haines <[EMAIL PROTECTED]> 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 DVCS > 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@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
