[RFC] Workingstyle of different VCS systems (more aegis stuff)

[Kuba Ober]

On Thursday 05 April 2007, Matthew Woehlke wrote:
> (Kuba Ober, we would like your thoughts too!)
>
> Andreas Pakulat wrote:
> > On 05.04.07 13:04:43, Matthew Woehlke wrote:
> >> Hmm... ok, I guess it's similar. I don't know how aegis works, so... :-)
> >
> > See the archive of last month, Kuba Ober tried to explain it to me.
>
> I know, I've been reading, but I didn't understand it either. :-)
>
> >>>>>>> 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?
> >>>>>>
> >>>>>> Um, I'm not sure I follow you. You "can't"* edit a file unless you
> >>>>>> open it for edit. Once it is open, you can move it around your open
> >>>>>> changelists. An open changelist basically just serves to keep track
> >>>>>> of different things you are working on at once, mainly you can
> >>>>>> pre-enter the description and you commit single changelists, so this
> >>>>>> makes it easy to commit some files but not others.
> >>>>>> [snip asterisk]
> >>>>>> The main practical impact here is that before you can hack on a file
> >>>>>> you have to "open" it (vcs'd files are usually -w until you open
> >>>>>> them). Changelist management I think is unique enough that it can be
> >>>>>> left to the front end to worry about.
> >>>>
> >>>> 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.
> >>>
> >>> As aegis needs something similar I think we should try to find a way to
> >>> execute some vcs-action before opening a file in the editor...
> >>
> >> No, this is totally unnecessary/wrong with perforce. Most opening files
> >> is "look, don't touch"; edit should be a separate action. Alternatively,
> >> if you could intercept trying to save a file, and if it is -w, /then/
> >> pop up a dialog asking if you want to open it for edit, that would rock.
> >> But files should not be opened for edit when you open them.
> >
> > Hmm, I'm not sure we can intercept it (I haven't looked at the
> > kate-integration).
>
> 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). 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?).
>
> >> Well, it's just MHO but tagging to me is a more complicated action that
> >> you need to take more care in doing than something I think I personally
> >> would want to put directly in KDevelop. Also it isn't as "directly" in
> >> the work flow as editing, committing, and even renaming, it is more "off
> >> to the side". But that's just MHO.
> >
> > 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.
>
> Hmm... ok, then maybe what I am thinking of as "tagging" is not what you
> are thinking of as "tagging". It sounds like you are thinking of what I
> call "branching". I'd be OK supporting that in the VCS interface. In
> perforce there are also "labels" which are a combination of a client and
> a revision number. So if you have /branches/3.5, you might have labels
> "3.5.0", "3.5.1", "3.5.2", etc, that correspond to a particular release.
> This might be "3.5.2 is /branches/3.5/... at revision 5127".
>
> What I am thinking of as "branching" would be e.g. creating
> /branches/4.0 containing the contents of /trunk.

In aegis, the model is similar and really conceptually simple. You have 
project baseline, which is just a directory owned by aegis, so it's read only 
to you, mere mortal :) There can be a bunch of other baselines, called 
branches, which shadow the project baseline. I.e. if you look for something, 
you look in the branches first.

You can have a structure such as:


/usr/com/aegis/foo/baseline [project foo's baseline]
  +
  +- /usr/com/aegis/foo/branch.1/baseline [baseline of foo.1]
  +
  +- /usr/com/aegis/foo/branch.2/baseline [baseline of foo.2]
     +
     +- /usr/com/aegis/foo/branch.2/branch.1/baseline [baseline of foo.2.1]

Then in your home directory you can have

~/foo.1.C010 [change 10 in foo.1]
~/foo.2.1.C021 [change 21 in foo.2.1]

When looking for file bar/baz.c in change foo.1.C010, you look in following 
places:
1. ~/foo.1.C010/bar/baz.c
2. /usr/com/aegis/foo/branch.1/baseline/bar/baz.c
3. /usr/com/aegis/foo/baseline/bar/baz.c

When looking for file bar/zod.c in change foo.2.1.C021, you look in following 
places:
1. ~/foo.2.1.C021/bar/zod.c
2. /usr/com/aegis/foo/branch.2/branch.1/baseline/bar/zod.c
3. /usr/com/aegis/foo/branch.2/baseline/bar/zod.c
4. /usr/com/aegis/foo/baseline/bar/zod.c

Essentially, branches isolate you from anything that happens at their level or 
deeper into the tree.

Branches are otherwise behaving just like any change would do, just that you 
can't change files directly into them. To modify a branch (any branch, 
including project's baseline), you have to create a non-branch ("regular") 
change.

The lifetime of any change is always the same:
1. create
2. modify (copy files, add files, remove files, move files)
3. build
4. integrate (implies a review, and another build)

Cheers, Kuba