Peter,
> 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
affected?
iii: The one I really like doing:
# ident /proc/2805/exe
/proc/2805/exe:
$Id: res_mkupdate.c,v 1.7.2.3 2004/06/10 17:59:43 dhankins Exp $
$Id: res_update.c,v 1.11.2.3 2004/06/10 17:59:44 dhankins Exp $
$Id: res_findzonecut.c,v 1.14.2.4 2004/06/10 17:59:43 dhankins Exp $
$Id: ns_parse.c,v 1.2.2.2 2004/06/10 17:59:40 dhankins Exp $
$Id: ns_sign.c,v 1.4.2.4 2004/06/10 17:59:42 dhankins Exp $
$Id: ns_name.c,v 1.1.2.5 2004/06/10 17:59:40 dhankins Exp $
$Id: ns_samedomain.c,v 1.3.2.4 2004/06/10 17:59:41 dhankins Exp $
$Id: ns_verify.c,v 1.5.2.3 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