[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