[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: Tim Hill <drtimhill_at_comcast.net>
Date: 2006-11-15 18:36:27 CET

I think I'm with you on this one, in so far as I consider it bad
practice to create such a "frankentag".

--Tim

On Nov 15, 2006, at 5:44 AM, Reinhard Brandstädter(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
>
> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 18:38:19 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.