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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jun 23 10:47:52 2003