RE: Fwd: Are complex tags bad, evil, from hell?

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

-----Original Message-----
From: Phyrefly [mailto:phyrefly.phyre@gmail.com]
Sent: Thursday, November 16, 2006 3:06 PM
To: Subversion Mailing List (E-mail)
Subject: Fwd: Are complex tags bad, evil, from hell?

(forgot to reply all, again - Fwd-ed)

This is starting to sound like an argument for not using source revisioning at all.

"If the developer doesn't comment a revision, we'll never know why he made that change"

Hell, let's all pack it in, and never write another line of code, just in case someone creates a bug, or someone uses the application to do something we didn't intend.

<Serious mode on>
The alternative to "frankentags" is to checkout different versions of different things, and commit them all as one revision, tag that, then get the original HEAD code and re-commit it over the top. How is that more useful? Surely this contains _less_ information, as we don't even know what revision that tagged code came from, much less why!

On 16/11/06, John Waycott <javajohn@cox.net> wrote:
> Reinhard Brandstaedter wrote:
> > Hi,
> >
> > This is not a technical question, it's more a call for opinions on a
> > general work process with tagging and release management.
> >
> > What I'm concerned about is the use of complex tags (described here:
> > http://svnbook.red-bean.com/en/1.0/ch04s06.html#svn-ch-4-sect-6.2)
> >
> > In short:
> > a complex tag is a tag created from a working copy that contains not
> > one single revision of a whole directory tree but where single
> > folders/subtrees or files are selectively checked out from different
> > revisions or even locations/branches.
> >
> > I'm talking about using complex tags for tagging stable versions or
> > releases of production projects. Why? Because developers and project
> > leads at my company do it that way and I think it's bad and have to
> > convince them it's bad
> >
> I would argue that complex tags are bad because there is little or no
> information stored that indicates why the complex tag was constructed
> the way it was. If you use earlier revisions of files A B and C but
> use the latest revisions of D E and F to get a stable release, why did
> you do that? What changes to A B and C prevent you from using the
> latest revisions? It is the historical "why" that is important to
> record. You could write a complex log message to describe it, but my
> bet is the developer will miss something.
>
> We forbid complex tags for this reason. Historically some groups did
> use them, but when it came time to debug field code, it was very, very
> difficult to figure out why certain revisions of files we selected.
>
>
> ---------------------------------------------------------------------
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 18:42:42 2006