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

Re: [OT] Updating a Tag

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2003-06-23 10:46:59 CEST

On Mon 2003-06-23 at 10:02:42 +1000, Daniel Patterson wrote:
> On Sun, 2003-06-22 at 12:42, Benjamin Pflugmann wrote:
> > The use case is: I want to mark a moving target. Like, the last
> > version that was tested to work (yeah, I can compile and run the
> > testsuite, but don't have the unique, external, expensive hardware it
> > controls for a real test, so my collegue some hundred miles away
> > should tag whenever he tested it works).
> > In other words, it is some kind of communication, some kind of
> > (mis-)use of the tag system and of course, there are other solutions
> > (he could write mails instead, or whatever). Maybe there is a *better*
> > solution I did not see yet (I would be glad to hear), but until I find
> > it, moving the tag is the most usable for us.
> Yes, I think there is. It sounds to me that the pattern that matches
> your use case is a *branch* not a tag.

It's not (for me). I tried it first.

> Let's assume that we make a tag immutable. This means there is no
> confusion between "why is my LASTEST_STABLE code different to your
> LATEST_STABLE code?", which is a good thing to have.
> Instead, have two (or more) branches. When someone has completed
> changes that are sufficiently stable, merge those changes into
> the "stable_changes" branch.

Currently, that means merging up to 10 times a day. Although that
might be caused by my own inefficiency or by the tools I use, merging
is a bit time comsuming process. I rather do not do it so often, if I
don't absolutely have to.

Aside from that, we already have a branching policy, and it is
different. It's overkill (in my eyes) to restructure the whole working
process in order to get a little commodity.

Take Subversion as example, would you really suggest, that every
developer works on his branch and merges his branches to the main
trunk several times a day, every time a check-in (to his branch) got
approved by the others? It would be possible, yes.

But they don't do it this way. And for a reason.

Say, that we just wanted a simple method that showed, when (some
specific user) run the testsuite of Subversion for MS Windows
resp. Mac last time, so that others get a feeling for it (if they want
to look). You are not necessarily interested in its history (you can
simply check out old versions and re-run the testsuite, if really need
arises). I cannot really believe centering your work process around

To keep somewhat on-topic, the way tags are handled (simulated) in
Subversion even gives a history to the process. But is there a better
way than creating a copy each time? Could one use some non-revisioned
property for this purpose?

> This gives you:
> a) Tags that don't move (which is good)

The used IDE (Eclipse) already requires a different use pattern for
moving tags than for adding tags, so there is not much confusion.

> b) A trunk that is potentially broken.

Already have that (per project-policy).

> c) A branch that people can be reasonably sure of
> (at worst, it's exactly as reliable as a moving tag)

We already have that. We keep it current to minor milestones.

> Note that the difference between tags and branches is pretty thin
> in CVS for starters, and as branches are so potentially confusing
> in CVS, it's pretty easy to misuse tags this way.

I am absolutely aware of the difference between tags and branches in
theory and in practice. I just don't have that much experience in
putting them into use.

> Just a final point. I've learned (through experience), that using
> tagnames like "LATEST" and "STABLE" alone, without any kind of
> incrementable portion is asking for trouble.
> You can pretty much guarantee that what you tag will *not* be the
> latest, nor will it be considered *the* STABLE tag forever.

Did you read the PS of my previous mail?

I absolutely do *not* use it this way. We have per-task branches (if
the task is more than one work-day), we have (several) stable
branches, we have release tags and so on.

I just want some functionality on top of that.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 10:47:52 2003

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

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