Tony,
I see your argument and can understand the advantages you mention. The FreeBSD
example is a really good one.
However I think it's not quite applyable to software development of one
project. In my case there is no dependency between single projects but it's
on Java-Classes, Model Documents and Testcases. If you want so it's one level
below creating a set of "tested" and "confirmed working together" as it's in
the BSD example.
I'm more with that what John said for the development of one project. Your
described process however is a good example how one could do configuration
management with SVN (e.g. for a company that has multiple products that can
ship together and have some dependencies)
Thanks for the input!
Reinhard
On Thursday 16 November 2006 18:39, Tony Harverson wrote:
> Hi There,
>
> I don't particularly want to argue against the case for simple tags.. While
> I don't think they'd be a great win for me personally, there does seem to
> be a collection of people who feel it would enhance their workflow.
>
> On the "Complex Tags/Frankentags" issue, however, I think the scenario
> being contemplated here requires a similar approach to the FreeBSD release
> tree (at least as far as I understand that release Process). I'm probably
> going to screw up the svn syntax somewhere here, but the general Idea is:
>
> 1) Branch the tree into an appropriate branch, using Remote copies, logging
> the reasons etc.
>
> - svn mkdir http://subversion/svn/repos/branches/Releng_6_2_0 -m"Branch for
> 6.2.0 Release"
>
> 2) Copy each library/subproject/component you actually care about into the
> branch.
>
> - svn copy http://subversion/svn/repos/trunk/Project1
> http://subversion/svn/repos/branches/Releng_6_2_0/Project1 -m "Initial
> commit of Project 1 - We've used version 17.274 because the 17.399 is
> unstable" - svn copy http://subversion/svn/repos/trunk/Project2
> http://subversion/svn/repos/branches/Releng_6_2_0/Project2 -m "Initial
> commit of Project 2 - We've used version 1.96 because the 2.01 requires
> Project1 17.399" (Could Also add Externals: info here, to pull in projects
> from outside the hierarchy)... ...
> ...
>
> 3) check out http://subversion/svn/repos/branches/Releng_6_2_0 and
> Compile/Test/Correct/Compile/Test
>
> 4) Once you're convinced you've finished the build, you can tag the thing..
> - svn copy http://subversion/svn/repos/branches/Releng_6_2_0/
> http://subversion/svn/repos/tags/6_2_0_RELEASE/
>
> And... 5)Release.
>
> Trunk@HEAD can be left alone, Bugfixes can easily be applied to the Releng
> branch, which can easily be retagged (either 6_2_0_Buildnumber or
> committing to 6_2_0_Release, but I'd say the latter is a bad and confusing
> Idea..), and you don't actually *need* labels (you always just want
> branches/Releng_6_2_0@Head, or tags/6_2_0_Release@Head, so you don't need
> the revision ID at all. This methodology also makes it easy to get a copy
> of the tag to investigate and fix bugs, means you don't have to futz with
> trunk@HEAD, and makes it easy to merge bugfixes from live to branch, using
> the svn or tortoise merge tools.
>
> The only problem I can think of with a setup like this is that you can't
> look at foo.c and see which tags it's landed up in (Although obviously
> looking at a file in a tag and seeing where it came from is easier).I think
> this really does argue in favour of a "Copied To" history item, which has
> been mentioned recently on this list.
>
> This may strike you as overly complicated, but if you're building a project
> with multiple dependencies and you want jagged revisions, I would imagine
> whatever toolset you come up with, you're going to have something of a
> complicated solution. Plus, at least this way, you have somewhere to
> commit a fix to the older rev to.
>
> This strikes me as the "Proper" way of solving it, while complex labels
> would result in a situation where storing changes to the old revision would
> be difficult, etc..
>
> Right.. I've opened mouth, I've inserted foot, time to echo
> internationally....
>
> Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 08:48:07 2006