On Mon, Jan 5, 2009 at 1:18 PM, Felipe Contreras <felipe.contre...@gmail.com
> wrote:

> 2009/1/5 Ali Sabil <ali.sa...@gmail.com>:
> >
> >
> > On Sun, Jan 4, 2009 at 11:33 PM, Olav Vitters <o...@bkor.dhs.org> wrote:
> >>
> >> On Sun, Jan 04, 2009 at 05:29:02PM -0500, David Zeuthen wrote:
> >> > Uh, but that's exactly how I understood the proposal and I believe
> that
> >> > the points I made (that you didn't respond to) still stands: That it's
> >> > crazy to officially want to support git, bzr and hg *at* the same time
> >> > *from* the same repo. It's just asking for trouble.
> >>
> >> That isn't true. It is Bzr on server, with Git support. Nothing about
> >> Hg, nothing about doing partly Git, partly Bzr.
> >>
> >
> > Sorry for not being clear in my explanations. Basically, as Olav pointed
> > out, it is about having Bazaar on the server, with a git-serve plugin
> > allowing it to fulfill the git client requests as well as the bzr client
> > requests.
> >
> > The following scenarios will be possible:
> > (bzr repo) <-> (git serve plugin) <--------- network -------> (git
> client)
> > (bzr repo) <-> (bzr serve) <--------- network -------> (bzr client)
> >
> > both bzr and git will operate fully, nothing will be partially supported,
> > since the bazaar repository format is a superset of the git repo format
> (ie.
> > it stores more metadata).
> >
> > I talked about hg, just to highlight that the solution is quite future
> > proof, because you can certainly apply the same solution to allow hg
> clients
> > to access the repository.
>
> First of all, who is going to develop and maintain the "git serve
> plugin"? Whoever does it I bet the end result won't be as good as the
> native git. Emulators tend to behave differently from the native
> counterpart.
>
> Second, as David mentioned; what would happen in the case the git
> protocol is updated and backward compatibility is removed? We will
> need to wait until the "git serve plugin" is updated, possibly
> rewritten.
>
> Third, every repository format has advantages and drawbacks. So far it
> looks like the git repository format works for most people, what is
> the need to avoid it?
>
> Fourth, we should not re-invent the wheel, people use either bzr or
> git, and not both for a reason; depending on a theoretical "git serve
> plugin" is just asking for trouble.
>
The way I understood the proposal, bazaar would be the official dvcs and a
usable- albeit officially unsupported- git wrapper would be provided.

Assuming that a future version of git doesn't introduce incompatibilities,
the approach has the advantage of being an easy solution which works for all
git and bazaar users. If a future version of git _is_ incompatible, the
official bazaar access would be totally unaffected.

That said, according to the survey most people use git. Most of those users
don't care about bazaar access at all, but might be slightly irritated if
there are any quirks with the git wrapper.

If you'd like to try to make everyone happy then the wrapper approach has
it's advantages. If you'd rather make a small group slightly annoyed and a
bigger group totally happy then go with git.

>
> Fifth, if the majority of the GNOME community prefers git, why degrade
> the git experience with an emulation? It makes much more sense for the
> bzr minority to emulate bzr experience with bzr-git if so they desire.
>
> --
> Felipe Contreras
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
-Natan
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to