[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

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.

> > 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? 

> > 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.

> > 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.

> > 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.

> > localVersion - gives the version of the local file
> East: that's just the file in the change you're working on.
> 
> > 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.

> > addignores - set information which files should be ignored by the VCS
> No such thing. In aegis, you have to add files explicitly into each change, 
> those would be the project files. Everything else is handled automagically.

Ok, so this is something for an optional iface and thus shouldn't go
into our base iface.

> > 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.

> > 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.
 
> > 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.

Thanks for the input.

Andreas

-- 
Your nature demands love and your happiness depends on it.