[RFC] Workingstyle of different VCS systems

[Kuba Ober]

On Tuesday 10 April 2007, Andreas Pakulat wrote:
> On 10.04.07 06:24:31, Kuba Ober wrote:
> > On Thursday 05 April 2007, Andreas Pakulat wrote:
> > > before I propose an update on the VCS interface I'd like to get
> > > people's experience with VCS systems. I have myself good experience
> > > with CVS and SVN but those two are pretty similar. I also used
> > > ClearCase about 3 years ago but don't recall the exact details.
> > >
> > > So currently we're aiming for something like this:
> >
> > 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.

> > > log - Show a complete history for a given local resource or VCS
> > > resource
> >
> > Makes little sense. What's a resource??
>
> resource could be a file or a dir mostly. Why does this not make sense
> with aegis? Don't you want to look wether a file was last modified in
> foobar.0.1 or foobar.0.0?

That's aegis -list change_file_history then :)

> > > diff - show a difference between local file and latest VCS version, or
> > > 2 VCS versions
> >
> > Makes sense, but there needs to be a way of choosing which "latest VCS
> > version" do we talk about. There can be multiple branches of parallel
> > development!
>
> Wouldn't that just be the version from which the changeset was created?
> I'm not sure atm whats the correct aegis-term, but lets say I created
> Changeset C10 from foobar.0.1, then diff should diff the file in C10
> with the same file in foobar.0.1 (if it exists there, else go to
> foobar.0). So if C20 changed that file and integrated the changes into
> foobar.0.1 then you'd see the difference between that and your local
> file.

Ok, that's probably a sane default.

> > > annotate - ==svn-blame, AFAIK, i.e. show which line of a file was
> > >            modified by whom in which version
> >
> > This is file difference tool specific, i.e. aegis itself is diff tool
> > agnostic and by itself doesn't know much about diff tools. This would
> > need to be made pluggable per diff tool used, i.e. diff-style,
> > fcomp-style, etc.
>
> 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.
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.

> > > repositoryVersion - gives the latest version in the repository
> >
> > In aegis, this needs to let you choose what do you consider as "latest
> > version". The most recent version in the timeline may *not* be what you
> > want - it may likely come from a parallel branch of development, and be
> > completely unapplicable to whatever you're doing.
>
> Thats not what I mean here. I mean just a simple versioning, not
> considering any branches.

Well, since development in aegis is done in branches, you need to choose 
something as the "most recent". Your upstream tree may be a reasonable 
default.


> > > merge - merges differences between 2 sources into the local file
> >
> > How is that different from update??
>
> update doesn't allow to pull changes from another branch. It only
> fetches updates made in this branch.

Well, it's pretty easy, then: cross branch merges can be done by hand, but you 
have to explicitly specify what branch you want to merge with. So for merge 
you'd have to tell it what branch to merge with. Update would do what 
aegis -merge does, then, as aegis -merge only considers upstream.

> > > revert - reverts local changes
> >
> > OK, aegis -remove - simply delete the file from a change.
>
> Well, only if it is not possible to integrate changes from a changeset
> into the branch the changeset was created from and keep the changeset
> alive, i.e. do further changes in the changeset.

Yes, it's not possible. The whole notion of "integration of changes" is more 
than that in aegis:
1. to integrate, a change must build, pass tests and review (tests and review 
may be nil, but if you make build a nil then you may as well use svn, not 
aegis)
2. once integrated, a change ceases to exist in its file form (the directory 
gets removed), it's only accessible via the project history mechanisms

Keeping the changeset alive has thus no sense in aegis: once the change is 
integrated, you can create a new, empty one, and it will "inherit" your 
previous ones in that branch.

> > > cleanup - fix inconsistencies with the local checkout
> >
> > OK, aegis -cleanup, this doesn't fix any inconsistencies, just removes
> > files generated by the build system and only leaves the source files
> > around.
>
> Thats a bit different in other SVN's. So I'm starting to think this
> should be done outside of KDevelop and not be included in our
> interfaces.

For aegis a change is just whatever has changed: added/renamed/copied files. A 
cleanup will remove everything else from the project's directory, thus 
removing any built files resulting from the change. You only need to do 
cleanup if you put a lot of temporary files into the change's directory, or 
if your build system is broken. Unfortunately, gnu make (and make lookalikes, 
such as nmake) are just that - broken and not supporting the aegis model. So, 
if you're unfortunate enough to use make, you'll be using cleanup *very* 
often.

> > > lock/unlock - lock a file or VCS resource
> >
> > No-op, what would that be?
>
> It would mark the given file non-changeable for everybody else until it
> is unlocked. You can make sure that nodoby else works on that file this
> way. Of course this is something that normally you shouldn't need in a
> SCM.

Yes, especially since aegis maintains ACID transactions on the repository, 
including for stuff such as builds. Builds are a critical section and are 
kind of an Achilles heel of aegis.

Cheers, Kuba