[RFC] Workingstyle of different VCS systems

Kuba Ober kuba at mareimbrium.org
Mon Apr 16 19:33:40 UTC 2007


> > 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.
>
> A merge /always/ needs three pieces of information' source original,
> source final, and destination. Usually the first two are revisions of a
> file, and the third is the same file in a different branch. 

In aegis, it knows all the files, so you don't tell it the files. You just 
tell it what is the source of a merge. It will always be applied to the 
current change (or any other active change you give it). If you don't tell it 
anything, it will merge the current change with upstream baselines. In aegis 
model, it makes little sense to merge a single file, since aegis rightly 
assumes that such a thing is unlikely to compile.

> Often you 
> derive this information from a range of revisions and a branch mapping
> (e.g. '/branches/KDE/3.5/...' -> '/trunk/KDE/...').
>
> I think this is another case of VCS's not using the terminology
> consistently. IIUC what aegis calls "merge", we are calling "commit".

No.

> A 
> "merge" (in our 'standardized' terminology) says "extract a change from
> the repo and apply it to my working copy".

That's what aegis means by that too, but by default a merge is always with 
upstream. Cross-branch merges have to be explicitly done if they are to be 
done in advance. If you don't do them, aegis will complain when the time 
comes to wrap up the parent branch.

Remember that aegis is a pretty full-blown SCM, and it depends on a bunch of 
other tools (build systems, file difference tools, test suites, you name it).

Cheers, Kuba




More information about the KDevelop-devel mailing list