[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.Beale_at_OceanInformatics.biz>
Date: 2005-07-29 13:04:58 CEST

Jacob Atzen wrote:

>On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
>
>
>>Sure, and that is of course our advice in our help pages. But it
>>doesn't mean that people will understand that these directories are
>>special; it is not always easy to educate users who are not familiar
>>with CM systems what trunk/tags/branches are about; some expect it to
>>be built in, others don't understand at all to begin with.
>>
>>
>
>There's just no substitue for education. If your developer don't
>understand it initially they _will_ have to learn. There's no tool in
>the world that will do this for you.
>
>You say you have a "releases" branch which only bugfixes should be
>committed to. This is only achievable by human means, no machine is able
>to determine wether a certain patch is a bugfix or a new feature and
>therefore no software will ever be able to enforce this rule.
>
>

Apparently I have not explained myself sufficiently clearly...what I am
suggesting is that knowledge of the directories
trunk/tags/branches/release be built into the tools at the client end.
This would be done in such a way that they would no longer appear in the
'normal' directory hierarchy but instead would (for example) display the
contents of those directories as views, or in some other way. Then other
rules could be attached to those views, such as the rule that the tags
view is readonly after creation and so on. Doing this just enables the
machine to implement the discipline instead of humans having to do it,
which is the current case. It would be easy enough to switch it off for
users who wanted to not have such a feature, so it would not be a
straitjacket. But if it were there, I think most users would choose to
use it.

- thomas beale

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 29 13:09:02 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.