Warping minds with the phrase "changeset"

Jan Hudec bulb at ucw.cz
Mon Jan 30 15:20:38 GMT 2006


On Mon, Jan 30, 2006 at 22:02:29 +1100, Martin Pool wrote:
> On 30 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> 
> > I have read the part and I'd say, that it's not changesets that allow
> > the cross-repository merges. What allows that are globally unique
> > revision identifiers.
> 
> True.  You could quite happily do cross-repo merges with only per-file
> changes.
> 
> > Note, that svk can do with just globally unique repository identifiers,
> > but it does not allow convergence. To achieve convergence revision
> > identifiers must be repository-independent, so you can copy a revision
> > and keep it's id.
> > 
> > Changesets are something different. They are first-class citinzens only
> > in quilt. In all version control systems, they are subordinate to their
> > base and target revision.
> 
> I think they are first-class in Darcs too; it doesn't really even *have*
> a concept of revisions.

I would actually say that before I wrote that very sentense. But there
is a difference between quilt and darcs that prevented me writing them
side by side. In quilt, patch is a patch, without any context. But in
darcs, patch depends on it's prerequisite set of patches, which makes
kind-of revision. So in darcs it's more sets of changesets than
individual changesets.

> Anyhow, I think it's fairly clear that the word 'changeset' is at least
> sometimes used in a way that encompasses what we do.  Google finds many
> people talking of svn changesets, and they don't even have unique ids
> (well, kinda, if you consider repo uuid + path + revno).

Yes, they are changesets. (One of the) definition(s) of changeset is: A
difference between two successive revisions. In this sense subversion
and even CVS do have changesets. Another definition (as in
"Changeset-CVS" or "CVS-Patchsets") is that it's a change introduced by
a single commit - and this spanning the whole tree.

The important points about merging don't really need to talk about
changesets - it can equally well talk about revisions. They are:
1. Commits atomically span the whole tree. This is important so that you
   don't accidentaly end up with a tree that only has part of some
   bugfix or feature applied (and is therefore in a broken state).
   Eg. in subversion there is a deliberate way (you can update
   individual elements only), in arch or bzr there is not. It is also
   important that you never merge just part of a change.
2. Revisions have universally unique IDs. This is important so that you
   can merge between repositories. There are actually two levels:
    a. Repository+local revision number. This is what svk does with
       subversion's uuid+revno (no path - commits span whole repo) and
       what arch did with it's hierarchical namespace. This allows
       merging remote branches, but it does not allow convergence.
    b. Some kind of unique identifier. This is what monotone, git,
       mercurial and bzr do. This allows merging remote branches and
       allows convergence, because revisions can be moved around while
       retaining their identity.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060130/1d6d4648/attachment.pgp 


More information about the bazaar mailing list