Are complex tags bad, evil, from hell?

[Reinhard Brandstaedter <Re...@jku.at>]

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

In my opinion using a complex tag to tag a version/release of an project
is really bad because:

a.) it's difficult to track which folders in the tag came from which
original revision or location. If you want to know where they came from
you have to check each folder in the log for it's "copy-from"

b.) resulting from a.) it's almost impossible to recreate such a tag
unless you still have the exact working copy you used before. Assuming
the complex tag is gone (I mean GONE, not in repository history or
whatever - unrecoverable) and the working copy is gone (who keeps
working copies stable forever?) you can't recreate the version just with
the history on trunk.

c.) isn't a complex tag more like selectively merging changes into a
specific branch and tagging this branch? This approach is not suffering
from a.) and b.) and thus has many advantages.


Arguments from project leads I have to fight are:
I.) we don't want branches! It's impossible to keep track of changes in
branches and merge them! There is no "integrator" (rem.: Isn't creating
a complex tag namely doing selective checkouts of folders/revisions some
kind of integration - deciding what goes in the release and what not?)

II.) People always commit to trunk, if some features aren't complete we
disable them in the application and they are not active - they only have
to be compileable.

I'd like to see your opinions on this!

Cheers,
Reinhard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

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

[John Waycott <ja...@cox.net>]

Phyrefly wrote:
> (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!
>
The alternative is to use branches as change sets and merge from the 
branches to get the features and fixes you need for a release. I don't 
like committing changes directly on the trunk (which is what complex 
tags encourages).

The bookkeeping for complex tags breaks down when you have to perform 
multiple commits for a single change. For example, I fix bug A, commit, 
then add feature X and commit. Now, I find the fix to bug A still has an 
issue. So, I make more changes and commit. With complex tags, I would be 
unable to easily select only the bug A fix for a release; I would have 
to check out the latest fix and then reverse delta the feature X change. 
I also no longer have a way to easily tell what changes were made to fix 
bug A.

-- John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

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

[Phyrefly <ph...@gmail.com>]

(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 <ja...@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

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

[John Waycott <ja...@cox.net>]

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

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

[Nikki Locke <in...@trumphurst.com>]

Reinhard Brandstädter wrote:
> On Wednesday 15 November 2006 15:30, Nikki Locke wrote: 
>  
> > How do you make a tag GONE? Surely the whole point of a revision control 
> > system is that nothing is ever gone? 
>  
> svndumpfilter might be a solution. But how to make a tag gone is out of scope 
> here. I wanted to stress that it's impossible to create the "same" tag (or a 
> tag with exactly the same content) again if you can't look closely at the 
> complex-tag. 
> If you don't tag at all (which no-one does!) you could still write down the 
> exact revision number on trunk that reflects a stable version in your 
> project-management papers and will still be able to recreate the version 
> until forever. 

I'm afraid I've lost the plot here.

You complain that you can't recreate the contents of a tag if it's gone.

I say tags never go away in this fashion.

You say you can hack the database using svndumpfilter to get rid of a tag.

Well, if you allow hacking the database, then any alternative solution you might 
propose is subject to the same difficulty. Make a branch instead, then the 
branch might have GONE in the same way, and you have the same problem.

So what point are you trying to make here?

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

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

[Reinhard Brandstädter <re...@jku.at>]

On Wednesday 15 November 2006 15:30, Nikki Locke wrote:

> How do you make a tag GONE? Surely the whole point of a revision control
> system is that nothing is ever gone?

svndumpfilter might be a solution. But how to make a tag gone is out of scope 
here. I wanted to stress that it's impossible to create the "same" tag (or a 
tag with exactly the same content) again if you can't look closely at the 
complex-tag.
If you don't tag at all (which no-one does!) you could still write down the 
exact revision number on trunk that reflects a stable version in your 
project-management papers and will still be able to recreate the version 
until forever.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

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

[Nikki Locke <in...@trumphurst.com>]

Reinhard Brandstaedter wrote:
> 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 
>  
> In my opinion using a complex tag to tag a version/release of an project 
> is really bad because: 
>  
> a.) it's difficult to track which folders in the tag came from which 
> original revision or location. If you want to know where they came from 
> you have to check each folder in the log for it's "copy-from" 
>  
> b.) resulting from a.) it's almost impossible to recreate such a tag 
> unless you still have the exact working copy you used before. Assuming 
> the complex tag is gone (I mean GONE, not in repository history or 
> whatever - unrecoverable) and the working copy is gone (who keeps 
> working copies stable forever?) you can't recreate the version just with 
> the history on trunk. 

How do you make a tag GONE? Surely the whole point of a revision control 
system is that nothing is ever gone?

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org