[RFC] Workingstyle of different VCS systems

Kuba Ober kuba at mareimbrium.org
Mon Apr 16 19:48:09 UTC 2007


> > > > In aegis, everything is done in a change, so the notion of a change
> > > > always is there in a background. Everything that happens is
> > > > manipulation of a change. A change should be thought of a working
> > > > directory in your home directory.
> > > >
> > > > > commit - let the VCS transfer local changes into the VCS
> > > >
> > > > In aegis, this is a multistep process, and ends with the change not
> > > > existing anymore. This has to be taken care into account.
> > >
> > > Well, than the plugin has to take care of this. I'm just looking for
> > > "actions" that we need, not how they are implemented at the end.
> >
> > The problem is that after a commit, none of the files the kdevelop may
> > need are there anymore.
>
> I feared that, I think thats going to be a problem. OTOH the aegis plugin
> could ask the project controller to close the project if all changed
> files are comitted...

With aegis, a "commit" is when you have to build, test, review and integrate a 
change.

The steps go like this: development build and test, change is still writable
development end - change becomes read only
review pass, integrate begin, build and test - done in a dedicated delta 
directory
integrate pass - this is the actual commit, when the branch (or project) 
baseline is actually modified (committed to). The delta and change 
directories are wiped at this point. Integration is a transaction that has 
guaranteed ACID properties with regard to the code building on all 
architectures, passing tests, and so on.

> > > Uhm, not its not. This should only show a listing of the file + the
> > > name of the author of each line in front of the line. Nothing more.
> >
> > 1. Aegis has no notion of file lines, files are just that: files, they
> > are not interpreted in any way (except for the project configuration
> > file). 2. You can use many different diff tools in aegis.
>
> This is not about diffing.

Kinda is, because you need a diff tool to know which lines have changed, and 
aegis to give you the files to diff. This is otherwise known as separation of 
responsibilities, the real unix way. Aegis is good at that. If anyone asks, 
why would an SCM do the job of a diff tool is beyond me.

> > 3. If you need such a detailed history, it'd need to be something that
> > has to be set up in a project-specific way, e.g. in my projects I don't
> > have it even set up simply because I never needed that feature.
>
> Aha, so aegis doesn't have a history of what part of a file was changed
> by whom. Does it know who changed a file last time? I guess annotate 
> should be  an optional function.

It knows all versions of all source files, and knows who modified the file at 
a given version. What it doesn't know is what has changed. To know that, you 
have to pass the version pairs to some tool which will tell you what lines  
or whatever (think binary files!) have changed. In case of graphics files, 
for example, you may want a file with the changes highlighted or somesuch 
(BTDT for multi-icon files).

Cheers, Kuba




More information about the KDevelop-devel mailing list