Hi Matt,
I kludged together a couple of other commit scripts that I had found in
various other places, and came up with the one I am using.
It's not pretty, but it works for us, for now. I have had more exposure
to perl since, and I need to rewrite it, but you can pull my last
version of the script here:
http://www2.thegrumans.net:8888/projects/svn/commit-mysql.pl.
<http://www2.thegrumans.net:8888/projects/svn/commit-mysql.pl>
This dumps the data into Bugzilla as a comment, and takes each file
modified and turns it into a link for ViewCVS to read.
On the subversion side, we are using TortoiseSVN, and I added the
bugtraq properties to link the commit comments to Bugzilla. For most
situations, this has worked very well. Since we typically perform one
commit per bug fix, I haven't tested this with multiple bugs in the bug
list.
If you need more detail feel free to email me offline, or (better yet,
and for all the others) start a new thread since this one isn't exactly
on topic. I had a thread going here
(http://svn.haxx.se/users/archive-2005-04/1896.shtml) if you feel you
want to continue that one.
Good luck!
Frank
Matthew Sanderson wrote:
>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
>>>
>>>
>>>
>>>
>
>
>
Received on Mon Aug 1 21:07:52 2005