Re: .dfm files check in as text in CVS leads to any corruption?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First, your e-mail has a silly disclaimer:

| This correspondence is confidential and is
| solely for the intended recipient (s). If you
| are not the intended recipient, you must not
| use, disclose, copy, distribute or retain this
| document or any part of it. If you are not the
| intended recipient please destroy this
| correspondence and notify the sender
| immediately.

[Note: This e-mail may be archived and used for
any purpose whatever and does NOT abide by the
quoted disclaimer given above. The author of this
message makes no claims as to the legality,
stupidity, validity, etc. of any message which may
contain the above notice.]

I am surprised that your company allows it to be
used when sending e-mail to a public mailing list.

You should inform your managers that your message
is being retained on many archives of the info-cvs
mailing list regardless of the intent of the
sender or the organization that has sender as a
member.

You really should contact the appropriate
postmaster or security manager at securemeters.com
and tell them they (and you) look like either
idiots or control freaks for sending such
statements on e-mail intended for a public mailing
list. Putting such a notice at the end of an
e-mail after it may have already been read by the
wrong person is also careless from a legal point
of view.

I will not actually quote your e-mail question as
that may divulge the nature of your "confidential"
message and we wouldn't want to make folks
happy...

Second, please do NOT send e-mail encoded in MIME
format to the mailing list. Search the web for
"html email considered harmful" and you will
likely find
<http://www.usethesource.com/articles/03/04/07/122224.shtml>
please take the time to read it.

Finally, you make a plea and mention "if I store
the .dfm files as text" somewhere in it without
actually giving any details on the file format.

Your message assumes that everyone must know all
the context needed via that simple statement. Of
course, to the general world at large "DFM" could
mean anything from an acronym of "Desktop File
Manager" or an abbreviation for "Det Fynske
Musikkonservatorium" or "Dubai Financial Market"
or some other really obscure and proprietary file
suffix.

So, let us assume it is the proprietary file
suffix from Borland given that you also may have
made mention of "Delphi" somewhere in your text...
Let me see... are ".dfm" files "Delphi/C++Builder
Forms" ? (This is, of course, a rhetorical
question as even if it were true I have no clue
about what lives in them... the format does not
appear to be published.)

If there are "Delphi/C++Builder Forms", I would
have thought those to be derived objects rather
than primary source files to be controlled. If
not, I would hope that a public format definition
that is able to be translated into simple ASCII
text should be possible... However, I do NOT know
if it is or is not.

(btw: Why are you asking an open source project
about files that YOU can look inside and we
probably can not? This seems a bit lazy to me. You
can probably answer your own question thru a
little bit of trial and error yourself.)

Now that I have denigrated your missive
sufficiently for the bad taste to be
"confidential" and in MIME text/html and to have
provided too few pieces of information to be able
to help you much, it is time to each you how to
fish for yourself.

Here is how you may be able to answer your own
question...

You might take a look at the contents of the .dfm
files you have saved and see if they look
'sensible' to a normal text editor. If it looks
like plain text, you may have lucked out and be
able to deal with text merges. Otherwise, you will
be out-of-luck. If there are lots of binary
characters in them, you are probably out-of-luck.

Now, take a copy of the file and check it into a
test repository. Check out two sandboxes (call
them treeA and treeB) from this test repository
which contains this test file and make two
incompatible changes to the file. Now commit the
first one from treeA and then do an update in the
treeB tree and see what happens. You are likely to
get conflict markers 'C' in the merge that happens
with the 'cvs update' command.

Are you able to make use of an editor to clear
things up and have a working .dfm file in treeB
which incorporates both the change that was
committed from the treeA file as well as the
change that had been worked on in the treeB file?

If your or your tools can figure out how to use
the merged data, then you are all set. Otherwise,
you are probably out of luck and will need to bug
your friends at Borland for aid.

I personally do not believe that derived objects
should be checked into a cvs repository if the
primary source files can be captured instead.

It is worth understanding that merging between
versions of an opaque binary format is beyond the
capabilities of cvs.

It is not currently possible to teach cvs to use a
tool other than diff3 with structured binary files
(although there is a proposal to do that being
discussed on the list).

I hope you find this information useful.

        Good luck,
        -- Mark

PS: E-mail from securemeters.com which has the
disclaimer in future will be deleted by my mail
user agent without me seeing the message. If you
can not find a free e-mail account without the
silly restrictions to ask your question, just
don't bother.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBIFw+3x41pRYZE/gRAv9fAKDWQ3PYKAJNK/aEcUZ8qP8toI5/nACgn8bv
h6M4JrTTQ/L4LSt9TkZRhNE=
=1wg4
-----END PGP SIGNATURE-----