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
>
>
Received on Fri Jul 29 15:39:21 2005