Take a look at: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html#svn.branchmerge.tags.mksimple
"But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch. If you are administering a repository, there are two approaches you can take to managing tags. The first approach is “hands off”: as a matter of project policy, decide where your tags will live, and make sure all users know how to treat the directories they copy. (That is, make sure they know not to commit to them.) The second approach is more paranoid: you can use one of the access control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags area (see Chapter 6, Server Configuration). The paranoid approach, however, isn't usually necessary. If a user accidentally commits a change to a tag directory, you can simply undo the change as discussed in the previous section. This is version control, after all!" On Tue, Aug 4, 2009 at 5:02 AM, James Carman<jcar...@carmanconsulting.com> wrote: > You aren't *supposed* to commit to tags, though. > > On Tue, Aug 4, 2009 at 5:00 AM, Martijn > Dashorst<martijn.dasho...@gmail.com> wrote: >> I can commit to a tag just as good as to the release branch. There is no >> spoon. >> >> Martijn >> >> On Tue, Aug 4, 2009 at 10:56 AM, James >> Carman<jcar...@carmanconsulting.com> wrote: >>> Ok, so show me how you would re-create the 1.4.0 release as it was >>> when it was released. What SVN URL would you use to do that? If >>> someone has checked in changes into your "release branch", you're >>> going to need to find what version (SVN version) was used along with >>> that URL to re-create the 1.4.0 release. It doesn't make sense to >>> have a non-SNAPSHOT version in your branch. Once a release is out, >>> it's out. You can't re-release 1.4.0 with different source code >>> (you'd have to do a 1.4.1 release). >>> >>> This is *not* normal SVN usage. Take a look at: >>> >>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html >>> >>> 1. Developers commit all new work to the trunk. Day-to-day changes >>> are committed to /trunk: new features, bug fixes, and so on. >>> 2. The trunk is copied to a “release” branch. When the team thinks >>> the software is ready for release (say, a 1.0 release), /trunk might >>> be copied to /branches/1.0. >>> 3. Teams continue to work in parallel. One team begins rigorous >>> testing of the release branch, while another team continues new work >>> (say, for version 2.0) on /trunk. If bugs are discovered in either >>> location, fixes are ported back and forth as necessary. At some point, >>> however, even that process stops. The branch is “frozen” for final >>> testing right before a release. >>> 4. The branch is tagged and released. When testing is complete, >>> /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The >>> tag is packaged and released to customers. >>> 5. The branch is maintained over time. While work continues on >>> /trunk for version 2.0, bug fixes continue to be ported from /trunk to >>> /branches/1.0. When enough bug fixes have accumulated, management may >>> decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, >>> and the tag is packaged and released. >>> >>> I'm "barking up the tree" because I am a member of the Wicket >>> community and an Apache Software Foundation member. We need to make >>> sure we're doing things the right way. The right way should coincide >>> with the way other folks reasonably expect it to work. This is not >>> how the Maven release plugin does releases. It does it like this >>> (which is the normal way Maven/SVN folks expect releases to work): >>> >>> * Check that there are no uncommitted changes in the sources >>> * Check that there are no SNAPSHOT dependencies >>> * Change the version in the poms from x-SNAPSHOT to a new version >>> (you will be prompted for the versions to use) >>> * Transform the SCM information in the POM to include the final >>> destination of the tag >>> * Run the project tests against the modified POMs to confirm >>> everything is in working order >>> * Commit the modified POMs >>> * Tag the code in the SCM with a version name (this will be prompted for) >>> * Bump the version in the POMs to a new value y-SNAPSHOT (these >>> values will also be prompted for) >>> * Commit the modified POMs >>> >>> >>> On Tue, Aug 4, 2009 at 4:41 AM, Martijn >>> Dashorst<martijn.dasho...@gmail.com> wrote: >>>> This has been the process since I've been release manager. Create tag >>>> when we cut the release, create release branch where we build the >>>> release from the tag, release it. If there's a issue, repeat. This way >>>> release artifacts don't pollute the main development stream, which is >>>> rather normal SVN usage. This way you don't have release specific >>>> commits pollute the diffs between releases. Only actual commits that >>>> are part of our normal development cycle are between release *tags*. >>>> Everything else that is specific for a release is in the release >>>> branch. And each release gets its own release branch. >>>> >>>> I'm not sure why you are barking up the tree though. >>>> >>>> Martijn >>>> >>>> On Tue, Aug 4, 2009 at 10:32 AM, James >>>> Carman<jcar...@carmanconsulting.com> wrote: >>>>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn >>>>> Dashorst<martijn.dasho...@gmail.com> wrote: >>>>>> I beg to differ: the way it is currently setup is the way we have done >>>>>> it since inception of wicket. >>>>> >>>>> No, I beg to differ. You haven't been doing it that way. Take a look at: >>>>> >>>>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml >>>>> >>>>> That is a release tag and it doesn't have a SNAPSHOT version. >>>>> >>>>>> >>>>>> tag -> the moment where we cut the release >>>>>> release -> the branch where the commits go to actually build the release >>>>> >>>>> Tags are supposed to be immutable. What would be the purpose of >>>>> creating a SNAPSHOT tag, unless you're taking a snapshot of the source >>>>> before some major refactoring or something? The wicket-{release >>>>> version} tags should be reserved for release tags (and thus the >>>>> pom.xml wouldn't have SNAPSHOT versions in them). The release tags >>>>> should be able to be used to re-create the release. You have to have >>>>> a tag for that or else your "release" branch (which you said gets >>>>> committed to) would be altered and it would differ from the actual >>>>> release (and thus you wouldn't be able to re-create the original >>>>> release with it easily). >>>>> >>>>> Why would you go against the way that everyone else uses SVN? >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>> Apache Wicket 1.4 increases type safety for web applications >>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.4 increases type safety for web applications >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
