On Dec 1, 2007 7:50 PM, Al Boldi <a1426z@gawab.com> wrote:
quoted text
> Not sure what you mean by operationally transparent?  It would be transparent
> for the updating client,  and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is not meant to change the server-side git-update semantic.

I guess what he means is that when your write to the file -- from your
editor -- it can't be considered a commit. During an editing session
you might write a dozen times, only to commit it once you are happy
(that it compiles, passes tests, etc).

quoted text
> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users.  But what the git model is
> currently missing is a client manager.  Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.

If you want a dumb-ish client CVS-style, you can try git-cvsserver.
But the git model is definitely superior -- "replicating the tree on
the client" is not a workaround but a central strategy.

Have you used git and other DSCMs much? From your writing, it sounds
like you may have misunderstood how some of the principles of git work
out in practice.

cheers,


m
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/