Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Kent Borg wrote: > On Fri, Aug 18, 2006 at 08:20:23AM -0400, David Kramer wrote: >> You know, I hear this all the time, but nobody has every been able to >> tell me what's so "scary" about it. What do you think the difference >> should be between a tag, a branch, and a copy? > > To my feeble/traditional/CVS-polluted mind: > > tag Symbolic name for a version. More descriptive than some > branch Something that has obvious and durable ancestry, something > copy A free-form thing. It is good to know where it came from > > Subversion is clearly powerful enough to implement these, but > out-of-the box it has no concept of tag or branch, everything is a > copy. Tags and branches are things that one must build by admonishing > users to follow a set of rules/conventions, or by using the tools > Subversion supplies to build higher level features. mkdir tag branch copy svn add tag branch copy Done. If you want some sort of extra control on any of those, implement it in any of the ways I mentioned. In fact, the Subversion book goes into great detail on how to implement this. There's no black art needed. > The scary part: If you don't have these ideas clear in your usage of > Subversion you can end up with tags that don't stand still, branches > where you are not clear what the key versions are when you want to > merge back into your main line, and a zillion other mysterious copies > proliferating for no disciplined reason, ready to explode if someone > makes the mistake of typing "svn co http://mysvnserver/svn" and > checking out your root. And if I give a Bushman from Australia a Miata, I'm guessing there will be a fairly high casualty rate. "If you don't know how to use the tool you can do damage" is just a stupid argument. If you aren't willing to spend two hours reading a book (complete with many examples) so you know how to use a tool your entire company is going to rely on, stick to Visual Basic. In fact, you're probably not ready for UNIX/Linux. You don't even have to *buy* the book. It's available online. > Yes, in a well set up system all of these things can be dealt with, > but out-of-the box Subversion is not a "well set up system". > Subversion is a powerful toolkit that requires further work before it > is "well set up". Don't get me wrong. I have no objection to general > purpose tools, but sometimes (to pick an extreme example) I would > rather be handed a spreadsheet than be handed a C compiler. Sooo... you want a version control system that forces every user in every environment to use the same exact directories and ACL, because it happens to be what you like? That sounds dreadful. I suppose you're also having trouble finding a Linux distro that comes with preconfigured with a "kborg" account and your favorite emacs macros. I'm sorry if I'm sounding snippy here, but I'm seeing a lot of FUD and misinformation in this thread.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |