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

Re: Proposal for $Revision$ keyword amendment

From: Miha Vitorovic <mvitorovic_at_nil.si>
Date: 2005-09-30 09:48:54 CEST

Hi all!

Since I only monitor this list, I am very reluctant to speak, but I feel
that I need to, now. Here are some of my observations.

I've seen this issue raised by a number of users, who many times feel very
strongly about it. I actually don't have much of a need for this feature,
but some people feel they can not live without it.

But I would like to point out, that the whole refusal of the developers
comes across as "we will not do it, because we think that it is stupid". I
am OK with that stand, and if it would take developers away from real
issues, of course I wouldn't like them to waste their time on something as
trivial as this. Or, if this would break current Subversion
functionality/system in some important way, of course everyone (well
almost) would understand that you can not do it. But I didn't see this
argument made anywhere (or maybe I missed it). It's more of a holy war,
that real issue.

But here you have someone who is willing to spend his time on this issue,
and still you argue, that it is stupid. And this, IMO, is really bad
advertising. Because those users who REALLY, REALLY want this, get the
impression that it can be done, but won't because the developers mean they
are stupid to want it in the first place. And people don't like to be
called stupid. And here is this guy offering himself to do it, but "they"
won't let him.

Don't get me wrong. I am not proposing the M$ way, where stupid features
are thrown in just to make customers happy, even if it means adding 10
more bugs to the code. But SOMETIMES it pays to make your "customers"
happy, by putting things in that you don't find very useful, but they do.
Especially if it means not doing much more beside saying "go ahead, do the
work, and will put it in".

> I strongly disagree. Even if you don't have a firm testing scheme (and
> you should), you can easily skip step 1 and just tag/switch/release.
> You don't even /need/ to do the switch, as long as your release process
> captures what tag you are setting in the source code some way. It could

> be automated or it could be manual. Copies are cheap and even if you
> have hundreds of custom releases, you can organize your repository to
> have project/tag/customer/release/... so that you don't go quickly mad.
> Or just tag based on your initials and the date (so it's easy to find
> out who to beat up for mistakes). ;-)

And, yes you are right of course, but the developers are (usually) smart
enough to know this, and they will use the tags, and they will
(presumably) not do the same mistake twice. But SVN is used for so much
more beside code development. Some people use it for document storage, or
any other kind of storage. And they aren't developers at all. Talk to them
about tags and branches, and they'll assume the conversation is about
wrestling in the forest.

And in the end, you sometimes simply have to let people do their own
mistakes. The ones that know nothing about SVN will read the book first
anyway. And if you hide this "global" revision number sufficiently, they
will learn to do things the right way, before finding this feature that
would cause all the problems described above.

Here's my $0,02.

Best regards,

  Miha Vitorovic
  Inženir v tehničnem področju
  Customer Support Engineer
   NIL Data Communications,  Tivolska cesta 48,  1000 Ljubljana,  Slovenia
   Phone +386 1 4746 500      Fax +386 1 4746 501     http://www.NIL.si
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 09:49:50 2005

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.