On Fri, August 3, 2007 3:39 pm, Jose Alberto Fernandez wrote: > Hum.... What we saw was that the plugin was using "svn copy" after fixing > the release version in order to commit the changes directly on the /tags > directory, i.e. tagging the modified working copy. > > And as someone else mentioned we do have an svn hook forbidding checkins > on > /tags.
An "svn copy" on the tags directory is the preferred way of creating tags, and by convention should always be allowed. It should be possible for tags to be created (using svn copy), but not for tags to be modified (using svn commit). > Does any one knows if there has been a changed on the way Release plugin > works on versions later that 2.0-beta4? Maybe is time for us to upgrade. Just double checked by doing an "svn log --stop-on-copy" on a release tag we created a few minutes ago, and the only log entry on this tag is the "svn copy" that created it. In other words, at no point was the tag ever committed to after it was created. The version of the release plugin in use is 2.0-beta-4, although the latest release is v2.0-beta-6. > Well, you know that by not specifying the version of your plugins, this > means that every member of your team may be using a different version? Yes I do, but this has nothing to do with the advice to use the default configuration. Specify the versions of the plugins, yes - but do not feel compelled to add configuration blocks for every plugin. If you do, you can change default behaviour in a way that breaks the plugin. Remember that once you have anchored the version of the plugin you are using, the defaults are guaranteed not to change. Regards, Graham -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
