Hi,
[ The same mail was sent to Larry McVoy for discussion. Still, I want that
these ideas are also available to and implemented in free version control
systems. ]
Code ist more than a simple textual representation of the things you want to do.
How about going one point further and using a programming language aware(0)
change detection in a source control system.
If I am changing the function foo(), the source control knows about
exactly that, not about the simple textual changes (you see, we are moving
from pure textual/line changes to some kind of semantic ones(1)), so this
knowledge can be applied later, if the function is moved around in the file
or even in the whole tree(*) and a patch to that function is applied later.
A similar method can be applied, if variables (collectively, any "symbols")
are renamed or (type-, context(+), ...) changed.
So, the patch paradigm is also moved from a pure textual/line/offset
representation (with various methods to overcome the limitation, e.g. fuzzy
offset detection) to a more semantic-aware mechanism.
Instead of focusing on pure textual changes, we are taking the "meaning"
into account.
This can be beneficial for a couple of reasons:
-In the changelog, you will automatically see the affected
functions/variables ("symbols") from revision to revision.
This is only the first step and a rather simple "context" information for
the changes.
-You now can comment on certain "context-enriched" or semantic changes
seperately, instead of the old "if I check in multiple files, _all_ those
file will get the same comment.(#)
[ I sincerely apologize for the word context-enriched, but I found nothing
better. ]
-You can, if you changed more than one "thing" in a file, check in certain
changes _selectively_ (you REALLY should have this possibility already with
current software, e.g. range-select the changes you want check in/check
out/diff/... in a GUI).
Example:
I want to check in the changes to function foo(), but not the ones to bar(),
but I rewrote bar() already -- with the old method, this is not easily
possible, once bar() or any other "thing" is modified in the file because of
its "whole file/tree changes" orientations
-The above idea can also be applied to multiple files, as usual ("I want the
changes from CHANGES, foo.c, foo.h and bar.c" like in
#> svn ci CHANGES src/foo.[ch] src/bar.c)
-You can check out one or more semantic changes _selectively_ instead of
_all_ (you may not want).(#)
-You will see a much more informative history of the changes to your code
and check in log-writing is more precise.
The whole idea behind this is to ease the creation and usage of "feature
check ins" and to not make check ins ultimatively "set in stone" or
unsplitable(-).
Problems:
-The data structures representing all that and keeping them compact
-Totally raised complexity
-Raised resource need in all areas (space, cpu time, ...)
If you have questions, please ask me directly, as I am not subscribed to
your mailing list.
Kind regards,
Freek
Footnotes:
----------
(0) We do need the parser for that particular language to supply us with the
necessary information.
Illustration:
int x, y;
means the same as
int x; int y;
or even
int y;
int x;
(1) If we are adventurous, you could even take (to various optimized levels)
code-trees as a measure to explore the change to the code.
Needs support from the used compiler, of course, but gcc has something in
the -HEAD code.
The infinite possibilities are left as an exercise for the reader.
(*) this may require a class/function/variable/... -> file mapping generated
from source
(+) For C, this e.g. means: Global, local, function local, naming, data type
and so on.
(#) requires good frontend support, much more than all of the current tools
support.
The old "all changes" should be not too complicated to do, though.
(-) Why not even make the changes individually selectable in the front-end
so only certain wanted changes (on diffent levels like the old "lines"
paradigma or the new "semantic changes") are merged into the working copy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 25 19:46:35 2005