Graeme Geldenhuys schreef:
I have written (or am writing) an application to identify which
revisions change the same files, so I can group them together in one
merge.
What if a revision changed more that one file (which happens often)?
I see no problem, it just helps me to see that two revisions depend on each other,
because they change the same file. (There are of course more dependencies, a new
feature in the LCL can be used in the IDE only if the LCL feature has been merged).
If there are two files in a commit, it may create a dependency on other revisions
which changes one or two of those files.
Wouldn't that cause problems. Also how would that affect me?
Not at all.
I use
Cherry-pick, which simply applies the original commit to the fixes
branch. This allows git users to see where the original commit came
from - full history of changes are kept.
That is nice.
Rolling various commits from trunk into a single commit will loose
that history?
The history is in the log message, as you found out.
That is why I don't use the standard automated branch
tracking in Git for the fixes branch. I use the commit log
descriptions in fixes branch to see what the original commit in trunk
was, and cherry-pick that original commit.
Not knowing exactly what you application does, but wouldn't that
interfere with the commit log descriptions?
It only helps to select revisions, I still use svnmerge.py merge to do the actual
merge. So no, it does not interfere.
Vincent
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
