Re: Git hosting

["Elijah Newren" <newren gmail com>]

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 haven't had time to play with named branches in mercurial to see how
well it currently satisfies this criteria.  It's clear that it's
better than bzr here; but I have heard of shortcomings in their
current implementation of named branches and I don't know if these
shortcomings affect this feature.

>  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:

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.

>  Maybe integrate with damned-lies. That knows the .po files (not always
>  in the same place, sometimes multiple in a repos, etc). Just need
>  something that makes it simpler.
>
>  I don't think there are scripts that change git --> usable though.

No public scripts that I know of......

>  > > - All DVCS can do something like svn export
>  > >   $vcs://$vcs.gnome.org/repos/path/$FILE right?
>  >
>  > Humm.  Not so sure.  Sounds like git-checkout really.

No, it's not git-checkout.  It's git archive; see my other email.

>  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...).