Warping minds with the phrase "changeset"

[Martin Pool]

On 30 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> 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.

I thought that quilt could express dependencies too, but I might be
wrong, and at any rate not to the same degree.

> 
> > 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.

I agree with your refinement of the definition, and would add to 2b that
this kind of naming also allows you to mirror or move branches with less
trouble, because the name of the location is not bound up in it.

-- 
Martin
-------------- 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/20060131/ad867a09/attachment.pgp