[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: early reflections on subversion methodology

From: Thomas Beale <thomas_at_deepthought.com.au>
Date: 2005-08-13 12:57:24 CEST

Monks, Peter wrote:
> G'day Thomas,
>
> <apologies for the HTML formatted email - I'm using a web based emailer
> that doesn't give me control over the format of my email>
>
> Perhaps I'm missing something, but if a particular revision is important
> for some reason (eg. for rollback purposes), why wouldn't you create a
> copy ("tag") of that revision elsewhere in the tree? That copy could

often you don't know in advance that you need to roll-back to some
particular revision...e.g. your developers might have introduced some
inconsistencies into the codebase without realising it for a few
revisions....

> (through the use of commit hooks) be read only, if that's a
> requirement. The nice thing is that instead of being a
> hard-for-humans-to-remember integer, this important revision would have
> a symbolic name (the SVN URL) that is likely to have a lot more meaning.

yes, but that only works for consciously tagged revisions, i.e. releases
of some kind...

>
> I guess I'm still missing why having a single tree that contains both
> the "special" namespaces (branches, tags what-have-you) as well as the
> contents of those namespaces is such a problem. Sure the system doesn't
> necessarily understand the differing semantics of these constructs, but
> I don't see why it would need to.

As far as the directory structure goes, it's just a pity that the
multiple development line 'views' (trunk, branchA, branchB, release1.0,
release5.1 etc) have to be visible in the directory structure which
otherwise is part of the controlled content; doing this makes it part of
the _controlling_ system.

>
> I've heard it said that a lot of software design is about striking the
> right balance between systematically enforced rules (which are
> inviolable but inflexible), and procedurally enforced guidelines (which
> are flexible, but more difficult to enforce), and it seems to me that
> Subversion pushes that decision out to its users (which, IMVHO, is
> ideal). I can go with the default mechanism where the "special"
> namespaces are up to me to define and enforce procedurally, or (through
> the use of such things as pre-defined repository structures and commit
> hooks) I can systematically enforce a particular CM metholodogy.
> Regardless, the key point is that Subversion doesn't lock me into either
> scheme.

No it doesn't. It just doesn't provide enough support for doing tags,
releases etc; all users are in the position of having to implement
something extra, meaning somehting unique and different at each site,
plus having to write procedures to help people learn how to use the
facilities to do what they way (e..g the issue of tracking branch paths).

- thomas beale

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 13 13:01:08 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.