Re: Git hosting

[Olav Vitters <olav bkor dhs org>]

On Wed, Mar 05, 2008 at 06:57:29AM -0700, Elijah Newren 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 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.

I have to read up on hat mercurial annoyance...

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

Meaning Git can do it, but it is painful, yet again?

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

You're comparing to SVN?

checkout + history is always going to be more than checkout only. E.g.
for sysadmin purposes I care about having a checkout, being able to
update that easily (without any possible merge errors), but I really do
not care about history / diff / etc. Complete waste of diskspace.

SVN is crap because it stores each file twice (for the diff).

Another question: I know git needs 'git gc' and that should be done
automatically. Are there other need to knows? Especially on the server
side? Is there stuff available to do a full mirror? Assume it should be
possible due to DVCS, but still.
E.g. Canonical goes down, and we just change the IP to the Red Hat
server. I know that due to DVCS people can continue to work.. but
still.. backups should be done anyway.. things should be up and running
in hours max (shorter is not possible with volunteer sysadmins).

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

Oh, svn revert. I was confused about all the different meanings, which
seemed to have no real purpose (can agree if for usability reasons --
but that wasn't the case).

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

Still magic to me... maybe I'll understand more after tonight (trying
commands from behdad).

For Git, we'd need to hire someone to fix it up.

-- 
Regards,
Olav