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.
Cheers,
--matt
Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
matthew@formtrap.com
http://www.formtrap.com/
+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