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.
-Corey On Feb 4, 2008 7:09 PM, Luis Lavena <[EMAIL PROTECTED]> wrote: > 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 > -- http://www.coreyhaines.com The Internet's Premiere source of information about Corey Haines
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
