Hello,
I just wanted to clarify something quickly.. When I credited the FreeBSD release engineering team for the branching and tagging approach, I may also have inadvertently implied that they use Subversion for their version control. In fact, they are still using CVS for their central repository.
Tony
-----Original Message-----
From: Reinhard Brandstädter [mailto:reinhard.brandstaedter@jku.at]
Sent: Friday, November 17, 2006 7:48 AM
To: users@subversion.tigris.org
Subject: Re: Fwd: Are complex tags bad, evil, from hell?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 12:47:37 2006