Re: Git hosting

["James Henstridge" <james jamesh id au>]

On 05/03/2008, Elijah Newren <newren gmail com> wrote:
> On Wed, Mar 5, 2008 at 3:37 AM, Olav Vitters <olav bkor dhs org> wrote:
>  >  > I add to that: Have entire project history offline.  Or at least have a
>  >  > usable option to do so.
>  >
>  >  Isn't that with any DVCS?
>
>
> No, it's not.  bzr does not have this ability.  See
>  http://blogs.gnome.org/newren/2007/11/24/local-caching-a-major-distinguishing-difference-between-vcses/
>
>  If you want just the history of a single branch, then bzr, hg, and git
>  will meet your needs.  If you want all history (I certainly do), then
>  bzr falls far short.  It's a Repository Formats Matter thing too, so
>  don't expect to see bzr obtain this ability anytime soon.

I think you are mischaracterising Bazaar's functionality here.

A Bazaar branch contains the entire history of that branch.  If I
merge some other branch into my one, then all the information
necessary to reconstruct any of those revisions will be present in my
branch (so I can diff against them, branch off them, etc).

So what you get is essentially the same information as if you pulled a
single head from one git repository to another.

If I want to track multiple heads at once, I pull multiple branches.
If my copies of those branches reside in the same repository, they
will share storage similar to when you manage multiple heads in a
single git repository.

There is the UI difference that the default "pull" commands of bzr and
git do different things (pull a single head versus pull a collection
of heads), but that has nothing to do with repository formats.  Could
you elaborate on what repository feature you're referring to?


>  >  Does it always get the whole history? Others allow e.g. only doing a
>  >  minimal checkout and using the remote server for missing info (saves
>  >  lots of diskspace).. that is bzr.. Hg I still need to investigate (I
>  >  really hate that file merge thingy).
>
>
> bzr provided super shallow checkouts first, i.e. just a working copy.
>  However, git did one up on them and allowed the user to download
>  "shallow" histories--anywhere between 0 and n commits.  bzr then
>  copied git's pack idea in the past couple months, in order to obtain
>  this feature and some of git's performance characteristics.  (Let me
>  also note that bzr has a number of nice UI abilities not found
>  elsewhere with such a checkout, allowing users to essentially operate
>  in a centralized mode.)  While this sounds cool, it really isn't all
>  that useful because:

Shallow branch support for Bazaar is currently in development, and
should be available in a few releases.  From Robert's initial tests,
he was able to create usable branches that contained only the local
changes, with a reference to another branch for the remaining history.

So if I make a one line fix to a project with a 100MB working tree
size, the shallow branch size will be proportional to the 1-line file
rather than the 100MB tree.  Of course, such a repository is useless
if you can't reach the base branch/repository containing the rest of
the data.

It could be useful if developers want to publish their own personal
branches on a gnome.org server without us running out of disk space:
If both the base repository and the developer's reopsitory branch are
on the same machine then it should be as reliable as two full-history
repositories.


>  Your assertion that shallow checkouts saves lots of diskspace is not
>  well founded in my experience.  It was certainly true of bzr when bzr
>  originally first implemented the feature, but these days systems are
>  able to get a full copy of the history plus a working copy and STILL
>  often take less space than an svn checkout.  Source code and its
>  changes over time compresses really well with smart algorithms.

The main reason why I use lightweight checkouts with Bazaar in my day
to day development are:

1. I like to keep my repository data separate from my working trees.
This makes backup easier, and I can blow away a working tree with no
danger of losing information (assuming I've committed everything I
wanted to).

2. I can switch the working tree over to another branch.  This is
useful if I come up with a bug fix while working on something else, it
is trivial to switch the working tree to another branch, commit, then
switch back.  I assume you do something similar with git.

3. While a working tree plus the entire history might be of similar
size to a Subversion working copy, I sometimes want to work on two
lines of development separately.  Sharing the history between the two
working copies is a definite win.

4. If I have no working tree for an old branch that I've merged, then
its storage requirements are a small constant value.


>  >  Hrm. Don't understand why all those commands have to have a different
>  >  meaning in Git. Reset that isn't reset, etc.
>
>
> I agree with the general sentiment, but the specific case is not
>  correct...there is no reset command in cvs, svn, hg, or bzr, so I
>  think git was free to use reset for something new...as they did.
>
>  I will note that a subset of the functionality from git checkout and
>  git reset often get confused with git revert.  Another nasty unneeded
>  UI wart (that is surprisingly easy to fix I might add...).

"git reset" sounds a lot like "bzr uncommit" is that accurate?

James.