[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Are complex tags bad, evil, from hell?

From: John Waycott <javajohn_at_cox.net>
Date: 2006-11-16 15:44:40 CET

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
Received on Thu Nov 16 15:45:42 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.