Hi,
+ external/zlib/zlib.dif
+ external/sqlite3/sqlite3.dif
+ Added .dif files for local patches to locally hosted
3rd party code. Pls update these when modifying original
source locally.
; NOTE: I intentionally didn't add svn props to these files.
Without native EOL it will be hard to update them for none Win/DOS
users
anyhow I suggest to remove them. They are redundant and such diffs
can be
always generated automatically using svn diff command and for sure
it's
much safer method then .diff files updated manually by developers.
If you want then you can simply add log file to store revision
number just
after committing new version of given library and before appalling
diff
generated for previous code. All new syncs should be done in the
following
steps:
1. generate locally .diff file from last library upgrade using
svn diff -r <revision> ...
if possible check <revision> number in log file.
This will give a diff between lib versions, but local
modifications won't appear separately unless they are
always repatched in separate commit after each upgrade.
But once this is missed by mistake, the chain becomes
broken and it becomes quite an effort to repatch it right.
2. commit new library source code
3. patch new library using .diff file generated in step 1 and
update log file adding information about current revision
number
4. commit modifications
The log file is optional but it can reduce time necessary to
validate exact
revision number from last library update.
Hm, current method with .dif isn't prefect either, but
IMO it more clearly documents the fact that we're dealing
with locally patched code, and it makes it easier to
separate patching and lib upgrading steps. Your method
puts all the burden to lib upgrader, which is IMO more
error prone.
We should also consider that patching sources locally
happens quite rarely and it should only be done if
absolutely necessary. Upgrading however, may happen
quite frequently (speaking of sqlite3, libpng).
.dif method also makes it easy to flush those patches
upstream (by any contributor) which would be the ultimate
goal after all, rather than rolling them locally forever.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
