[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: Matthew Sanderson <matthew_at_formtrap.com>
Date: 2005-08-01 01:28:28 CEST

Hi Frank,

+1 for arguments against the probably-illusory 'defacto standard'.

What sort of integration did you make with Bugzilla, and how did you do
it, may I ask?
We may drop Bugzilla (we're not terribly happy with it). But if we do
stick with it, close integration with svn would be nice to have.



Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
+61 (02) 8303 2407

On Fri, 29 Jul 2005, Frank Gruman wrote:

> Your point is an interesting one, but I too would have to disagree with
> your stance of creating a 'defacto standard'. In my development
> environment, it made more sense to change the names of the directory
> structure. No one in our development team understood what a 'trunk'
> was, or branches, or tags. So we called ours Main, Beta, and Releases.
> Most of the work is done on Main. When we get to a build, that code
> goes to Beta so that Main line future functionality can continue while
> testing is run. If there are bugs found in testing, they get fixed on
> Beta and eventually merged into Main. Once we get to a good point
> there, things go to Releases. Only managers are allowed to make any
> changes to Releases. I could also restrict Beta, but our dev team
> rotates through Beta dev fixing and mainline dev.
> It works for us. That's what I really like about Subversion. It
> allowed us to set it up in a way that made sense to us. We didn't have
> to learn some other guys' idea of what a repository structure should
> be. I control access to things through pre-commit hooks and
> mod_auth_svn. My developers have fallen in love with cheap copies. It
> took me a couple of tries, but I have integration between my
> repositories and Bugzilla, so no commit can be done without some sort of
> Bug / Issue # being attached for all of the documentation of why changes
> are made. The more I talk about it, the more I love what Subversion has
> allowed me to do.
> All in all, I think the subversion developers are approaching it
> properly in allowing freedom of repository layout. If you do want
> something more 'standardized', I think I saw another post referring to
> building a __client__ that enforced whatever structure you want. That's
> the beauty - you can take the server and data inside of it and put
> whatever top end on it you want. But not at the server level.
> Don't change my Subverion... :-)
> Regards,
> Frank
> Thomas Beale wrote:
> > 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
> >
> >

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 01:30:13 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.