Re: [Gnu-arch-users] Re: the state of the union

[Tom Lord]

    > From: Mikhael Goikhman <address@hidden>

    > On 17 Aug 2004 19:45:43 -0700, Tom Lord wrote:

    > >     > From: Miles Bader <address@hidden>

    > >     > I thought that "changeset orientation" just meant that all changes
    > >     > to a source tree can be committed to the repository as an atomic
    > >     > step, and these atomic steps have convenient names.

    > >     > Doesn't subversion have this...?

    > > Subversion fails to be *usefully* changeset oriented because it is
    > > *uselessly* changeset oriented:

    > I tried to find a compact description for my slides, so I asked about this
    > on #svn several days ago.  I got a compact answer, "changesets are not
    > first class objects in svn, that is the case in the systems like arch".

That's a crappy answer and is not the best they've given when other
people have asked similar questions.

If you do some archaeology you'll see that for the first few years of
svn they thought they were building something arch like in the sense
that it would have smart branching and merging based on atomic
whole-tree commits:  i.e., they *thought* they were building a
changeset system.

They screwed up *precisely* on the issue of logical file ids (which
svn lacks).   So, they wound up with an atomic commit system with 
fancy branching features --- but anemic merging features.  You can
rename files in subversion but if you rename then just *on a branch*
then subsequent merges to or from that branch are horked.   They can
"fix" this without adding file ids for a subset of cases, but there
will be plenty 'o edge cases they handle poorly unless they add file
ids.  They have repository-level changesets rather than tree-level
changesets and consquently, they have trouble applying those
changesets across branch boundaries within a single repository.


    > They don't think this is a flaw, because one may implicitelly refer to
    > the changeset in "svn merge".  I replied that, yes, explicit changesets
    > are kind of redundant for strictly centralized non-distributed systems.

Not really.  You want/need changesets as soon as you have branch and
merge commands.  The goal of "Distribution" adds some constraints:
e.g., changesets have to be "portable" between repositories --- but
the need for changesets originates from branching and merging, not
distribution.

-t