Bzr development stopped

[Talden]

On Tue, Nov 27, 2012 at 11:24 AM, Jelmer Vernooij <jelmer at samba.org> wrote:

> On Tue, 2012-11-27 at 09:33 +1300, Talden wrote:
> > On Sun, Nov 25, 2012 at 3:55 PM, Jelmer Vernooij <jelmer at samba.org>
> > wrote:
> >         On Sat, 2012-11-24 at 18:20 -0800, Chris Hecker wrote:
> >         > I may be in the minority, but I don't care that much about
> >         the ui or
> >         > simplicity of the command line, but I need to be able to
> >         rename files
> >         > without duplicating them in the repo, I want empty
> >         directories, I want
> >         > the hybrid centralized stuff (and more of this, actually),
> >         and I need
> >         > windows support to be good.
> >
> >         FWIW, git and bzr deduplicate storing renamed files in roughly
> >         the same
> >         way. In both VCSes renaming a file generally shouldn't cause
> >         that files
> >         contents to be stored more than once.
> >
> > I assume here that you mean a vanilla rename, a change in path only
> > rather than path + content.  For Java development that never happens
> > (well tending towards never) - renaming or repackaging a class changes
> > the content and the location of the file.
> >
> > For Subversion that's a copy+modify and a delete (IE not really a
> > rename but at least it's not duplicating data).  Git, I thought, just
> > adds the new file and removes the old - deduplication only occurs if
> > the content is unmodified (same hash).  Does bazaar avoid the
> > duplication in a non-trivial move - these are very common in our
> > projects where we regularly refactor?
> Yes, Git indeed doesn't store the fact that there was a rename
> explicitly. Inferring the rename later could be problematic as other
> posters in this thread have pointed out. However, whether or not rename
> detection works isn't related to how much space the file contents will
> take in the repository.
>
> Neither Bazaar nor Git simply store the difference between the old and
> the new version of a file. They both store the difference between the
> new file and whatever other file in the repository is most suitable.
>
> Obviously there are some heuristics involved (not exactly the same in
> bzr and git) to find the best base against which to generate the delta,
> but this approach seems to work well enough.
>

I'm interested about how Bazaar does this (and git for that matter)...

You effectively have the following information when committing a file...

1. The hash of the file you're committing (or some other computed identity
that recognises content, not tree-location or ancestry)
2. The history of the file you're committing. non-empty for a
modification.  empty for an add.  non-empty if renames are supported.
3. Other changes in the same commit.
4. The entire data-store of history.

So, in a rename+modification scenario, while svn would delta the file
against it's immediate ancestor content or match an existing
representation...

I'm guessing git would
a) look for an existing rep using the hash
b) look for a good base using ancestry and commit information.

I'm assuming that git doesn't hunt the tree or history in a general sense
'for a good base' because that would take far too long (and scale terribly
with populous trees or deep histories).

Does Bazaar essentially do the same (whether or not it uses the rename
knowledge would seem academic in anything but a massive commit)?

In which-case I see what you mean, using git as the back-end might have
very little impact on storage and it's only the meta-data that we'd miss.

--
Talden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20121127/dd8c2c5b/attachment-0001.html>