Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

subversion



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org