I'm sorry but I do not agree. For me it's only unnecessary job which
can be eliminated by committing clean version of new library in 1-st
step what for me is the perfect solution.
I do not understand why I have to watch for modifications create
diffs with local copy of original source, update them, etc. in each
commit (I do not believe it will happen without errors) and on
each update I have to repeat things I can made without any diff
file using SVN.
I do not see anything what we can benefit having such .diffs files in
SVN. For sure they do not help in any updates because to create them
it's necessary to compare with original library so it will be always
safer to create .diff file just before an update to be sure that no
one
forgot to update the one in SVN. IMHO it's only unnecessary additional
job for developers which can be source of potential problems if
someone
use such not updated or wrongly updated (i.e. developer was too lazy
and created .diff entry "by hand" with mistake) .diff instead of
generating new one so it will not help in future upgrades.
In summary you are asking developers to use SVN to replicate SVN job
manually. Creating .diff files is one of the most important thing in
different versions systems.
No, I'm asking to not make much more difficult job what was
so far an easy task (or at least split the effort), and which
was done so far exclusively by me. (i.e. upgrading foreign sources
inside our repo)
So for me personally two options are left:
1) I won't upgrade any embedded sources which have any patches.
2) I will continue to upgrade to original version and will leave
repatching to someone else.
Any other options poses too much much of a burden that
I care. (note that I don't use sqlite3 for example, so
for me even such small patch just doubles/triples any work
that needs to be done on each update, and I'd rather spend
time on something more exciting. This is even true for the
current .dif solution. F.e. in this case I had to reapply
patch manually.)
Overall I'd see it much more ideal if these patches would
be submitted to original developers and we'd eventually
get them as part of the normal update process. This way
there would be no need for continuous redundant work either
for updater or developer (or both). I've already submitted
several reports and patches upstream, and some of them
made it to the next version, so I can only encourage
everyone to do the same.
In the future we may upgrade to GIT or some other VCS
system which is able to pull fresh sources from foreign
repositories to automate such upgrade process, so any
manual task which accompanying it might not be a viable
option anymore. [ or we need to automatize local patching,
by applying locally stored .dif at build-time. ]
[ maybe there is some industry standard solution to this
problem, which I'm unaware of though. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
