You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Freek <fr...@gmail.com> on 2005/02/25 17:41:06 UTC
Source Control: Revisited
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
Re: Source Control: Revisited
Posted by Noel Grandin <no...@peralex.com>.
And frankly, having worked with a version control system that works at the method level (IBM VisualAge), I prefer simply
embedding the intelligence into the merging process - eclipse's CVS merge tools are a good example of this.
Embedding too much "intelligence" into the version control system results in an inflexible and fragile system.
Stellation is a good example of putting the intelligence into the wrong place - it undoubtedly represents a lot of work,
but you have to buy into a whole development style in order to use it.
Rather do one thing (version files) and do it well. This provides a well understood mental model for developers to work
with.
Gerco Ballintijn wrote:
> Jani Averbach wrote:
>
>> On 2005-02-25 18:41+0100, Freek wrote:
>>
>>> Hi,
>>> 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.
>>>
>>
>> http://www.eclipse.org/stellation/
>>
>> Motivation and Goals:
>>
>> Fine granularity and Dynamic Program Organization. Stellation CM
>> will manage and version small artifacts, such as method
>> declarations, rather than entire source files. Fine granularity
>> makes it possible for programmers to coordinate their work with
>> greater precision, and to understand the impact of changes more
>> easily.
>>
>> As in general I found this as an interesting idea, but there are more
>> important things to do, as locking (almost there!), merge tracking,
>> replication (at least read only slaves), new WC library, SQL backend,
>> etc.
>>
>
> See also the following paper:
>
> @Article{MensT:2002may,
> author = "Tom Mens",
> title = "A State-of-the-Art Survey on Software Merging",
> journal = "IEEE Transactions on Software Engineering",
> volume = 28,
> number = 5,
> pages = "449--462",
> month = may,
> year = 2002
> }
>
> Gerco.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html
If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com
Re: Source Control: Revisited
Posted by Gerco Ballintijn <ge...@cwi.nl>.
Jani Averbach wrote:
>On 2005-02-25 18:41+0100, Freek wrote:
>
>>Hi,
>>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.
>>
>
>http://www.eclipse.org/stellation/
>
>Motivation and Goals:
>
> Fine granularity and Dynamic Program Organization. Stellation CM
> will manage and version small artifacts, such as method
> declarations, rather than entire source files. Fine granularity
> makes it possible for programmers to coordinate their work with
> greater precision, and to understand the impact of changes more
> easily.
>
>As in general I found this as an interesting idea, but there are more
>important things to do, as locking (almost there!), merge tracking,
>replication (at least read only slaves), new WC library, SQL backend,
>etc.
>
See also the following paper:
@Article{MensT:2002may,
author = "Tom Mens",
title = "A State-of-the-Art Survey on Software Merging",
journal = "IEEE Transactions on Software Engineering",
volume = 28,
number = 5,
pages = "449--462",
month = may,
year = 2002
}
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Source Control: Revisited
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-02-25 18:41+0100, Freek wrote:
> Hi,
> 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.
http://www.eclipse.org/stellation/
Motivation and Goals:
Fine granularity and Dynamic Program Organization. Stellation CM
will manage and version small artifacts, such as method
declarations, rather than entire source files. Fine granularity
makes it possible for programmers to coordinate their work with
greater precision, and to understand the impact of changes more
easily.
As in general I found this as an interesting idea, but there are more
important things to do, as locking (almost there!), merge tracking,
replication (at least read only slaves), new WC library, SQL backend,
etc.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org