presenting the fundamental abstractions

[Erik Bågfors]

On 9/12/07, Andrew King <eurokang at gmail.com> wrote:
> To further my own understanding, and to help put off a few of those
> similar questions I have been asked by my colleagues, I thought I
> would try and write out a bit of an explanation of bzr concepts. In so
> doing, I came up with some questions as well. Anyway, I thought this
> might be a good way of fixing my misconceptions, or starting a
> concepts section on the bzr wiki. (As it is written by someone who
> isn't a bzr developer, hopefully I may have more idea of what people
> don't "get" (including me!).
>
> Unfortunately, I came up with 4 components, not 3, so that is a bad start :(
>
> ==========
>
> bzr fundamental components
>
> This is an attempt to explain how bzr works in terms of its
> fundamental components, rather than in terms of work flow or use
> cases.
>
> 1. Revisions -
>
> At its most basic, bzr tracks revisions. A revision is a set of
> changes to one or more files, with associated metadata (such as the
> author).
>
> A simple example of a revision may be adding a single file, or
> changing one line in a file. More complicated revisions could be
> additions, deletions and changes to hundreds of files.

I actually do not think this is 100% right. It's right "enough" for
understanding.
But, I think a revision is not the changes to one or more files, but
rather the current state of all files in a branch at the point in time
when that commit was done (unless it was a partial commit of course).
To get to the changes, you need to compare this revision with the one before.

Am I right in this?

/Erik