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

Re: svn:keywords ... a plea

From: Graeme Vetterlein <graeme_at_vetterlein.com>
Date: Wed, 26 Mar 2008 22:08:41 +0000


> Thanks for the email. I went through exactly the same exercise last
> week and, like you, was stunned that auto-props was a client-side
> option AND that it was next to impossible to find good examples of
> this mysterious config file anywhere. At least I'm not alone.

No, I think a lot of folks hit this problem, some have only met one or two
version control systems or only done one style of development so have yet
to realise.

To clarify:

1: This is not a "theoretical comment" . Within the past year I have seen
     many man-days lots trying (unsuccessfully) to work out what version of
     a class was running in "the real world".

2: Just because 'you' can't see why a feature is needed is no excuse for
making it
    hard to use.

3: There are many things that are version controlled , not just a
single executable

Let me give a few examples:

i: A 'static library' (i.e. foo.a) the object code in this finds it's
way into many executables (a.out).
   When a a.out is found to be broken, it's obviously vital we can find
out what version of a given '.o'
   is in the linked file. It's all very well that we put a (single)
revision number in our archive, but we can't
   complain when the customer reports that foo_method1() is broken and
sends you his linked edited program.
   (HE might not have well controlled build process)

ii: A .jar file containing a set of utilities , which worked when we
shipped it, but somebody has misapplied a patch
    because the checksum has changed ... but which class file has been

iii: The one I really like doing:

# ident /proc/2805/exe
     $Id: res_mkupdate.c,v 2004/06/10 17:59:43 dhankins Exp $
     $Id: res_update.c,v 2004/06/10 17:59:44 dhankins Exp $
     $Id: res_findzonecut.c,v 2004/06/10 17:59:43 dhankins Exp $
     $Id: ns_parse.c,v 2004/06/10 17:59:40 dhankins Exp $
     $Id: ns_sign.c,v 2004/06/10 17:59:42 dhankins Exp $
     $Id: ns_name.c,v 2004/06/10 17:59:40 dhankins Exp $
     $Id: ns_samedomain.c,v 2004/06/10 17:59:41 dhankins Exp $
     $Id: ns_verify.c,v 2004/06/10 17:59:42 dhankins Exp $
     $Header: /proj/cvs/prod/DHCP/dst/dst_api.c,v 1.1 2001/02/22
07:22:08 mellon Exp $
...goes on for a while

(this is dhcp3 , by the way)

This shows which versions of files are inside the text region of the
running code. This is REALLY useful
if the code has dynamically loaded .so or .class files. You can find out
what code DID get loaded ... then
you need to work out WHY.

iv: Things like document templates. Each template has a version, each
file produced from that template
     need to inherit the version number.

v: Macros. The (users) code might not work because they macro-expand
(our) version1 code, then used the version2
    product. They've since upgraded the macros to version2 ... but they
forgot to redo the macro-expand process ... we
    need to find out what versions of (our) macros generated the code.

... lots and lots

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-26 23:10:27 CET

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.