[RFC] Workingstyle of different VCS systems

[Kuba Ober]

> >> merge - merges differences between 2 sources into the local file
> >
> > Merge is usually a complex operation which might require manual solving
> > of conflicts, further committing and such. Do we really need to expose
> > it to scripts/code?
>
> Yes, because otherwise you have to leave KDevelop to do a merge. One
> objective is to avoid having to use external tools for common
> operations. (Note that resolve() is also in the interface.)
>
> ...but I've never heard of a merge requiring "further commits", usually
> the merge is something you do to generate changes withing the working
> copy, *then* you commit.

In aegis, that's precisely what happens. A merge will look in the files which 
are in the current change, and modify them appropriately. The concept of 
merging with a branch doesn't readily apply to files not in the current 
change, as they are in the baseline already, ergo always up to date.

Now, for branch merges, you have to explicitly create a new change (or work in 
a change) and do a branch merge -- this will modify files in your change such 
that the branch merge would be effected after you integrate the change.

Bascially, in aegis the only way to modify any file, in any baseline, is to 
have a change modify such a file. Aegis keeps some metadata with each file, 
which tells it whether the file underwent a branch merge and such. If a 
branch is ready to be integrated, all files in it must be merged. If any 
aren't, aegis politely tells you to create a new change, merge the needed 
files, integrate that change into the branch, and retry.

> Otherwise you are talking about non-atomic 
> commits (ok, cvs is like this AFAIK) which are IMO broken. :-) Anyway, I
> don't see the problem.
>
> >> revert - reverts local changes
>
> D'oh, that reminds me... in perforce, there is also 'revert if
> unchanged' although really this is more like the opposite of edit(). The
> interface that has edit() should also have unedit() (or whatever name).

aegis -copy_file_undo -unchanged :)

> >> cleanup - fix inconsistencies with the local checkout
> >
> > I saw a discussion about this. Cleanup in svn is something that I don't
> > remember to see in CVS or ClearCase. The perforce's 'sync -f', isn't
> > revert?
>
> Yes and no, 'sync -f' means forcibly re-checkout *everything*, so it is
> a combination of revert everything and also check out anything you might
> have been missing, accidentally deleted, etc.

So that's very different from aegis, where aegis -clean will remove all files 
that are not part of the current change (all generated files, editor temps, 
whatever).

> We already agreed the "cleanup" won't make an interface, as it is too
> VCS-specific. :-)

Good call.

> >> copy - copy a file with VCS methods (history is kept)
> >
> > You cannot copy with history in CVS...

Neither in aegis, and I really doubt what would be the use. You're really 
creating a new file that happens to have contents of another file, the 
history starts at that point. In most environments, only such interpretation 
makes sense. Think of source file copying: if you need the original, just use 
it, don't duplicate.

> >> move - move/rename a file with VCS methods (history is kept)
> >
> > Same here. I have the feeling that this copy/move shouldn't be in the
> > interface.

Rename is a common thing and should be there. Probably only CVS is braindead 
enough not to fully support it, aegis and svn do support it (svn: AFAIK).

> >> mkdir - create a new directory in the local checkout and add it to
> >> the VCS
> >
> > I suggest to use mkdir from KIO and add from the interface.
>
> I think we either agreed to drop this or to implement it as KIO mkdir
> plus add(), since it really only applies to svn. Probably drop it (but
> provide a non-VCS mkdir in kdevelop), since either you will be adding
> files, or if you really only care about the directory (and are using
> svn), you can do non-VCS mkdir + VCS add by hand.

Yeah. I don't know about CVS here, but in aegis an empty directory isn't. If 
you need it for builds, you nominally add it in the build script. Otherwise, 
aegis only knows of files, not directories. Directories are only a stepping 
stone for file paths in aegis.

> >> resolve - mark a conflicted file as resolved
> >
> > Belongs to the VCS plugin only.

Aegis does that automatically, using your diff toolset of choice. In aegis, 
once a merge is successfully executed, it's considered done. In aegis, a 
merge is usually all-or-nothing. With fcomp, which is methink the preferred 
diff tool for aegis, it will always modify your files, marking up any 
conflicts in-line with some uncompileable hash (/-/-/-/-/-/-/-... lines by 
default).

> > This might make sense, altough it is somewhat against the idea to hide
> > the VCS type. But to offer full power to the users, this is good to
> > have (together with a getVCSinfo to actually find out what VCS system
> > is used). Perforce's "integrate" could be a nice candidate to be
> > performed with this.
>
> No, perforce's "integrate" is used to implement merge(), because that's
> what it does. :-)

Aegis's integrate causes the change to vanish (I mean, it's integrated so you 
should use the baseline to look at the read-only files, not the change).

> > tagging was mentioned in the thread. It is probably worth to have. But
> > branching should (the actions can be different in VCS systems).
>
> I forget what the consensus here was. In perforce, copy()/move(),
> merge() and branch() are all implemented by "p4 integrate", and then
> there is maybe tag() which is the same as branch() in svn but totally
> different in perforce.

In aegis, anything branch-related makes close to zilch sense from inside 
kdevelop. There may be a generic plug-in for aegis which manages all 
the "other" stuff, but this would be something like a separate tab or a menu 
entry, not directly integrated with anything but aegis database.

Before you have a change created somewhere, everything is read only in aegis. 
A project in aegis is like a root branch. Merely creating a project, and 
populating it with optional branches, does nothing much. To work on anything, 
you need a change.

> > Regarding the need of an "edit" action before actual edit, this could be
> > done the following way: the framework could have a
> > signal "documentAboutToOpen" to which the VCS plugin listens and do
> > what is needed to allow the editing.
>
> Nothing needs to be done on open AFAIK. However I think we need the edit
> interface because scripts probably won't open the file in the editor
> part in order to manipulate it. :-) And this means we should have 'unedit'.

In aegis, all files are read-only and have to be accessed in the baseline, 
until you copy them into the change, at which point you access them from 
change's directory and they become read-write.

What aegis does need is not an onOpen signal, but an onSave thing which would 
then tell katepart (or whatnot) whether it's ok to save, and what's the new 
name. In aegis, if you've opened a file that's not in the change, and then 
you go on to save it, you have to aegis -copy it into the change and 
overwrite the file in the change's working directory.

> Huh? I do *NOT* want my changes committed when I save the file locally!
> That's not the way it usually works.

In aegis it would even be impossible, as a "commit" is done on all of change's 
files, and it's really called an integration. An integration vapourizes the 
change :)

Cheers, Kuba