[RFC] Workingstyle of different VCS systems

[Kuba Ober]

> >>>>>>> Sounds a bit like aegis which Kuba uses... So if you have a number
> >>>>>>> of files in your changelist you can't just edit them? You have to
> >>>>>>> do this via a p4 command?

Well, it's even weirder than that. The files are in the project. A project 
directory will be available on your machine, typically via nfs or samba, or 
some other distributed sync mechanism (unison works fine for that, too). A 
change, by default, has no files. Say you're working on foobar.2.1, where 
foobar is the project name, and 2.1 is the current brand new branch. You 
create a new change, which is called foobar.2.1.C010 (change 10). What 
happens is this:
1. ~/foobar.2.1.C010 is created, which is the change directory / work 
directory
2. it's an empty directory
3. if you want to get to a file, you have to look for it in:
   I.   ~/foobar.2.1.C010
   II.  /usr/com/aegis/foobar/branch.2/branch.1/baseline
   III. /usr/com/aegis/foobar/branch.2/baseline
   IV.  /usr/com/aegis/foobar/baseline
   in that order.

Usually, you'll add some script magic to the project's configuration, such 
that when a new change is created, the .kdevelop* files get copied to it.

When a file is in the change, it's editable. If it's not, it simply doesn't 
exist in your work directory, and you have access to the *read only* baseline 
files.

> >>>> Yes, thats exactly what I was thinking, i.e. you can't just click on a
> >>>> file in the project which opens it and then edit it. You first have to
> >>>> execute some vcs-action to do that.

In case of aegis, that's exactly what has to happen! If the file is 
foo/bar/baz, then you'd execute the following commands

aegis -copy -project foobar.2.1 -change 10 foo/bar/baz

> Offhand I would guess you can't, but IMO that's OK. I'd say let's stick
> with a manual 'edit' action, at least for perforce (maybe aegis wants to
> do this differently).

As long as it's one click away, maybe it'd be acceptable, otherwise I'd hardly 
call it "integration" of aegis.

I'd say a file should always be openable, but it should be shown as read-only. 
Then when you right click in katepart's window, or on the tab, or on the file 
list, there should be a context menu entry to "make editable". This will 
execute the relevant vcs thingo.

> Anyway I think we are again drifting into back end 
> implementation and away from interface design. :-) I guess maybe we
> should keep in mind that a VCS plugin may want to hook certain events
> (maybe Kuba Ober could comment on this?).

See above for what implementation I'd consider "good enough".

> > Well, I think it depends. On a large project like KDevelop its certainly
> > not apropriate, however if you're working on your own small project that
> > you do release sometimes it might be convenient to not have to switch to
> > another client. As I said I don't know about other VCS' but with svn its
> > just a plain svn copy and thats pretty easy.

I've worked for ages with current kdevelop and doing all the aegis 
manipulations by hand. It's tiresome and wholly unnecessary. Kdevelop is 
there for a reason - it should do all that for you.

In case of aegis, the integration is much tighter, since an aegis-managed 
project has pretty fixed way of building it: essentially aegis -build and you 
don't care what other maketools etc. are used, it's supposed to be handled 
during project setup.

Cheers, Kuba