The perfect revision control system
goran at krampe.se
goran at krampe.se
Mon Feb 18 09:28:31 UTC 2008
Hi all!
Matthew Fulmer <tapplek at gmail.com> wrote:
> > *) "Cherry picking" of changes. Smalltalk, with its simple syntax and
> > keyword arguments, is the best language I know of for writing self
> > documenting code. But what is still missing is the *why* and *how did
> > we get here*. Intelligent use of change sets can go further to answer
> > those questions. When one makes a series of changes to fix multiple
> > bugs, they can after-the-fact move the changes into a separate set for
> > each bug so that later maintainers of the software have more
> > information to determine if the existing code is still relevant, etc.
>
> DeltaStreams can do this, but I haven't made the UI yet to be
> able to copy changes between deltas.
Yes, the model with Deltas is very similar to ChangeSets in this respect
and the only thing missing is good UIs on top.
> > *) Labeling. In big companies using sophisticated revisions systems
> > (i.e. not obsolete stuff like SVN), people are branching, merging and
> > conflicting all the time. Then when it comes time to release their
> > software they apply a "label". This tags the latest version of all
> > data managed by the system so that in an audit, they can conclusively
> > prove what the state of the software was for any version. This also
> > gives benefits to the system by allowing it to ignore everything
> > previous to the latest label (since the current state of the system is
> > simply: the latest label and all changes after that).
>
> DeltaStreams does not do this.
Right, the concept of tags is... hard to see how it would work in DS
given its model.
I haven't thought much about honestly.
> > *) Fully distributed. Anyone can make a copy of a given repository at
> > any time. They can make changes that stay only in their own copy, or
> > push them up if they wish. To make a branch, just make another copy
> > of the repository. The repositories are updated strictly through the
> > mechanism of applying patches so your totally free to "cherry pick"
> > changes out of someone else's repository (and the patches don't have
> > to be applied in order) or sync up if you wish.
>
> DeltaStreams as yet currently has no concept of remote streams
> or repositories. Since DeltaStreams is alpha software, it has
> known missing features. This is one of them.
Given the approach I would say DS is distributed. But it is hard to
compare - the "commands" you mention that are "standard" in tools like
Darcs/BazaarNG/Mercurial etc don't really have a counterpart in DS yet
since we haven't attacked the S-part (streams of Deltas) yet.
We have been developing bottom-up and thus we will first have a full
ChangeSet replacement before attacking the concept of streams of Deltas.
So the field is open but again, DS does not really *aim* to give the
same work model as Darcs/BazaarNG/Mercurial etc. That doesn't mean it is
not possibly though, we just haven't been thinking about it like that.
> Currently, I'm bootstrapping this by hooking onto the existing
> update stream supported by Squeak (See class Utilities, category
> updates, for how it works). The file format I'm currently
> writing interleaves a binary tree serializer with a normal
> change set. http://www.squeaksource.com/InterleavedChangeSet .
> In this way, you could build a delta with all the metadata
> available and file it out. The receiver would make use of all
> that metadata if DeltaStreams is loaded; otherwise it sees a
> regular change set.
Which is bloody genius. :) Sorry, I haven't been able to code on DS for
a long while, but it is great to see Matthew pushing it forward!
> It is still alpha stage; the writer is about 70% complete, and
> the reader hasn't been started yet. DeltaStreams doesn't yet
> know how to use it either.
>
> > *) Multiple ways of managing changes. Since the system will live in
> > the normal Squeak system, it has access to all the subsystems in the
> > image and can leverage them to apply or forward patches. One example
> > of this is darcs cool feature of letting a remote user make a change
> > and use one command to have darcs package up the change in the correct
> > diff format and forward it to the package maintainer for peer review.
>
> No idea what you're talking about here
I understand it I think. The "mail bomb" thingy that Darcs had early on
and that the oher tools have added. I would say this particular feature
is *inherent* in DS - since a Delta is a self contained thingy and yes,
feel free to send it through different means of communication.
Other areas of integration can be discussed - for example, if Deltas can
replace ChangeSet fully - should MC1/2 use Deltas (when doing the final
apply-operation) instead of ChangeSets in the future? And so on.
> > *) Compatible with other systems. Of course no new revision system is
> > going to have a chance if it can't deal with packages from all the
> > other existing systems. It may even be interesting to generate
> > packages from these other systems.
>
> This is the feature I'm working on next in DeltaStreams.
> Specifically, I want to be able to convert Installer scripts
> into deltas. Installer is a great way to specify what goes into
> a certain release and what does not. I think so, at least. Maybe
> you have a better idea with your darcs knowledge.
I am unsure what Matthew means when he says "convert" - would it be
simply "recording" all changes being done into a single Delta or?
Otherwise I would say that DS is the "tool" in this area that has most
chances of co-existance given its very trivial model and design. It is
something we really aim for.
> > Well, that's the list off the top of my head. I know MC2, and even
> > MC1 can do much of this (or probably all in the case of MC2), but MC1
> > is based on snapshotting which I disagree with and I think MC2 tries
> > to do too much.
>
> I don't see how "doing too much" can be a very serious problem.
> Colin has great ideas about MC2, and I'm curious to see if MC2
> and DeltaStreams will work together independently, if one will
> kill the other, or if there will be a need to merge them.
> Impossible to say right now.
Right. My bet is that MC2 will (if it gets to that state) eventually
replace MC1. If we bring DS to its full potential I hope it will replace
ChangeSets with all that comes with that - and also work as "glue" in
the world of Squeak code sharing.
I want people to feel that, "ok, hmmm, let me just file this out as a
Delta and ftp it up there/email it to you/drag and drop it to that other
image" or whatever. I want them to feel that when all else fails Deltas
are there to work as a very nice fallback mechanism.
And I also hope the apply/unapply feature will open up new ways of
working.
> > I believe the "theory of patches" underlying darcs
> > that any system is simply the sum of applying all it's patches, and
> > therefor I don't think anything more then this is needed.
>
> Goran wanted deltas to work just like darcs patches when he came
> up with the idea. However, I don't know anything about darcs,
> and I've written most of the DeltaStreams code so far, so I have
> no idea if what I am building lines up with that original goal
> or not.
Let me just note that while being *impressed* with Darcs I feel that
route is simply too complicated. I am inspired by Darcs, but I don't
want to copy it. I want to enable some similar feel of cherry picking -
but the idea was to make DS handle say 80% of the cases but using a MUCH
simpler trick (recording more state) than using highly advanced
algorithms that only 2-3 people even understand.
> Also, Goran has since discovered Bazaar revision control, and (I
> believe) found it superior to darcs. I know nothing about
> either; just mentioning it for completeness.
"Superior" only in the sense that it seems to do much the same but using
simpler means. And having tons of other features and a lot of developer
momentum.
Darcs still probably has the most advanced cherry picking out there -
but since the others are very good too - it doesn't outweigh the other
stuff.
> My current goal is to get delta streams working well enough to
> be of assistance while I try to merge the separate versions of
> Morphic in the various forks, and assist Edgar with Ladrillos:
> http://www.squeaksource.com/Ladrillos
Good, real usage is a great way to see if it holds.
> How I plan to use it is as a shared log that could reliably
> replay a set of changes made to a between a set of packages.
> Monticello has issues when moving classes between packages,
> which I envision needing to do a lot in dividing up Morphic. So,
> I want to use deltas to keep track of what I do while moving
> things around, since that is the most reliable order of making
> the changes. Eventually, Morphic should be divided sanely enough
> to use plain Monticello.
Very interesting use case.
> The features I will need for this to work are:
> - a reliable file-out format, in progress
> - Integration with Monticello, so that package saves and loads
> are correctly stored in the log
>
> So, this is all I'll be working on before I stop work for a
> while and concentrate on the release process.
Sounds great.
Hopefully I will be able to at least catch up a bit. :)
regards, Göran
More information about the Squeak-dev
mailing list
|