I'm by no means an expert on CM... I tend to use it in a very simplistic way,
but I do have a few comments and perhaps a suggestion or two below.
On Saturday 21 June 2003 10:42 pm, Benjamin Pflugmann wrote:
> Hi.
>
> On Sat 2003-06-21 at 14:21:12 -0700, Michael Price wrote:
> > --- Shlomi Fish <shlomif@vipe.stud.technion.ac.il> wrote:
> > > On Sat, 21 Jun 2003, Robert Pluim wrote:
> > > [ Do some work]
> > > cvs tag -F LATEST_DEVEL
> > > [ Do some work, and have another latest devel ]
> > > cvs tag -F LATEST_DEVEL
> > >
> > > Understood?
> >
> > Yeah, I understand. However, I feel the need to point out that moving
> > tags is EVIL, EVIL, EVIL! Its sad cvs makes it so easy.
>
> IMHO, the real problem is, that it allows to move tags, but doesn't
> keep history about it. If you could display a log history for the tag,
> it wouldn't be that much of a problem anymore.
>
> > > > Well, you've just destroyed part of your history.
> > >
> > > Actually I did not. The entire history is kept in the trunk. The tag is
> > > just a snapshot of it, which I don't mind updating to the latest one
> > > somehow.
> >
> > Actually you did. When you move a tag you've destroyed history. Period.
>
> Depends on the point of view. For his use-case, he knows before-hand,
> he is not (deeply) interested in history.
>
> > This is why moving tags is EVIL.
>
> Only if your main purpose of tagging is to keep history (which, of
> course, is *the* main purpose for tagging).
>
> The point is, there is a certain use case, and moving tags in CVS
> apparently is the best solution for the use case. At least, it's the
> best I have come up with. Same for him, apparantly.
>
> 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).
>
> Yes, he could use unique tag names, but that would mean more than 10
> tags on some days. Not really useful. So he moves the tag around. And
> we tag "worthy" versions with a unique tag, based on the "moving"
> tag. There are other variants of this scheme, so we have about 5-10
> moving tags overall.
>
> 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.
Here is where I see the biggest issue. If the idea is to keep a tag on
something that points to the latest version that works, then perhaps the way
you are using source control needs to be restructured. Again, I'm no expert,
but it seems to me that you should probably branch from the HEAD of trunk in
the repository, make your changes, and merge them back when it all works and
is tested. That way the HEAD of trunk will always point to a version that
works.
As a suggestion (and I really don't know if this would work or not), but
perhaps you could create an entry "latest_working_version" or something, and
use the svn:external property to mark the revision. Again, you don't really
get history here since there is no property history, but you could add pre-
and post-commit scripts that keeps a simple text file of all the revisions
the tag was attached to, just in case you needed to go back to it sometime.
Maybe someone will chime in here and say whether this would work or not. :-)
>
> > Most projects I've been on explicitly disallow tag moving.
>
> Yeah. We also have tags which are prohibited from moving. In fact,
> almost all. All without a special name part (all "moving" tags contain
> the nick of the developer who is allowed to move it). Long story
> short: I agree completely with your argument (for historic tags), but
> simply claim that there are other reasonable use-cases for tags.
>
> Bye,
>
> Benjamin.
>
>
> PS: This discussion reminds me a lot of the one on per-file logs with
> Subversion. There were overwhelming voices that one "wants" to use
> change-sets and it took some time until it got heard there we knew
> that and that we wanted changesets with separate per-change *and*
> per-file comments, in order to be able to ignore the per-file
> remarks for other files while viewing one with svn log.
>
> In other words, please don't let an agenda to get rid of an evil,
> let you prevent from seeing other valid uses.
> That is not directed to you, personally, Michael. This is not the
> first time this happened, and I feeled a certain urge to write
> about it.
>
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 22 15:27:16 2003