adler at stephenadler.com
Thu Aug 17 18:41:40 EDT 2006
Believe it or not, I like the fact that there is no tag or branch, just
copy and merges.
I think is quite an elegant solution. It does put the responsibility on
administrator to make sure the trunk and release directories are
protected from users.
What I'm doing is setting up the following access model to my repository.
Only users can checkout a branch, and preferably each user works on his
when the user is done with their major coding, then the administrator
does the merge
into the trunk and then the release administrator makes a release from
Anyway, its yet to be seen if this model will work well or not.
Kent Borg wrote:
> On Wed, Aug 09, 2006 at 04:50:33PM -0400, Stephen Adler wrote:
>> Anyone with experience using subversion, if you
>> could comment, I certainly would like to read them.
> In a previous life I converted an employer to CVS and in my current
> job I set up Subversion (replacing *NO* source code control, if you
> can believe it--and it is not a new company).
> I like Subversion, but I have one serious gripe: it is too general
> purpose. It will do everything you need for source code control, but
> it doesn't have the *specific* facilities you need. Want to tag a
> version? There is no "tag" command. Really. And that is a feature!
> To tag something you make a copy (which is efficient, using something
> like links). Want to make a branch? Again, there is no facility for
> branching your project. And again, this is a feature. The correct
> way to do it? With another copy. (Again, an efficient copy.) You
> can also make copies in subversion, the new copy will be under control
> and its history will reflect where it came from.
> So what is the difference between a tag and a branch and a copy?
> Nothing, not as far as Subversion is concerned, it is all a matter of
> how you use the two different copies. Want to start making changes to
> your tag? Fine. Subversion will let you, and you now have turned
> your tag into a branch. And if a coworker doesn't notice and quickly
> grabs the thing named "releases/version2.1.3" s/he will get the most
> recent version of "version2.1.3" not the original "version2.1.3".
> Out of the box, Subversion thinks they are all the same: tag, branch,
> or copy. Very scary.
> It is great to have a general purpose tool, but sometimes it is nice
> to have a specialized tool (for, say, source code control), that leads
> you in the right direction. A tool that anticipates the N things you
> are likely to want to do, and provides a way to do those N things, is
> very nice to have.
> Subversion has made a religious choice that they will not provide the
> facilities you need for source code control, not if a disciplined use
> of their general purpose features will accomplish the same thing. I
> think this is a mistake. It is really easy to screw yourself with
> Subversion by doing something dumb at the beginning (when you don't
> yet know what you are doing). A targeted tool is nice because the
> naive user will follow his/er nose and get a conventional result. It
> is only later, when the more subtle feature is needed, that the now
> not-so-naive user digs deeper for the extra feature. In the case of
> the general purpose tool you need to make wise decisions up front in
> how you choose to use the tool.
> Don't get me wrong, Subversion has been valuable. And other than
> maybe putting too many things in a single repository (multiple
> repositories would have been smarter--I think), I don't think I have
> been burned. But if someone commits new stuff in the "releases"
> directory, I probably won't notice. Yes, Subversion has facilities to
> prevent such things (probably to have me write a pre-commit hook
> script), but I wish that sort of thing were built in. The idea of a
> "tag" is a pretty fundamental part of source code control to leave
> The day a less elegant (i.e., more focused) source control tool comes
> out that has the main features of Subversion I will be badly tempted
> to change. If it also supports distributed repositories (which
> Subversion does not), then I am probably wanting to move on fast.
> Sorry to be so slow in responding to this thread. I get behind in my
> -kb, the Kent who wouldn't dare post such things on the Subversion
> mailing list, for they would flame him to a crisp.
> Discuss mailing list
> Discuss at blu.org
More information about the Discuss