Date: Mon, 29 Aug 2011 18:01:01 -0700 From: Julian Elischer <julian@freebsd.org> To: perryh@pluto.rain.com Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org, philip@freebsd.org Subject: Re: Official git export Message-ID: <4E5C364D.7070904@freebsd.org> In-Reply-To: <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <CAJ-Vmo=v0UkQarauKrvWKdjMTC81BwXmyhU__rnaQeL3z45L-g@mail.gmail.com> <slrnj5ddgp.4ck.vadim_nuclight@kernblitz.nuclight.avtf.net> <CAMBSHm8uX45k0M4on=5Cpw_CKoddA=4oJSNXpH7dGPt=Vy2HOw@mail.gmail.com> <alpine.BSF.2.00.1108261000040.48200@fledge.watson.org> <slrnj5lc58.jd1.vadim_nuclight@kernblitz.nuclight.avtf.net> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/29/11 8:39 PM, perryh@pluto.rain.com wrote:
> Philip Paeps<philip@freebsd.org> wrote:
>> On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote:
>>> Vadim Goncharov<vadim_nuclight@mail.ru> wrote:
>>>> May be FreeBSD should really write it's own VCS, just as Git was
>>>> modelled after proprietary BitKeeper?..
>>> Good luck getting agreement on what to model it on :)
>>>
>>> Personally I would suggest ClearCase as a model, but that's
>>> largely because I'm familiar with it.
>> Wait... you're familiar with ClearCase and you want something
>> that's modelled like it? Most people familiar with ClearCase
>> consider it to be a dire warning of what a VCS can become, not
>> an example. :)
>>
>> I think any system where the server has to keep track of every
>> client's files is pretty much obsolete in 2011. It scales
>> unbelievably poorly.
> The VOB server does keep track of every view's[1] checkouts, but
> I consider that a very low-level implementation detail -- there's
> no reason in principle why that record couldn't be kept in the view
> instead of in the VOB. (In a distributed system, which is what
> FreeBSD needs, checkout records _can't_ be maintained centrally.)
Having worked with mercurial, I would argue very much teh opposite.
With a distributed system one spends all sorts of time making sure
that what YOU think
is in release X is what the guy you are helping debug thinks is in it..
Gone is the ability to say "That came in with rev 23456 so if you are
later than that you have it."
p4 does a much better job of merging between branches etc because it
has teh big picture.
and you always know that if someone has change X that he also has
change Y.
Eventually one gets around these problems with distributed systems
by using the distributed system to simulate a non distributed system.
e.g. Only pull from the central source so that you know wht the heck
you are working with.
but if you are going to do that, then why not actually USE a central
source that is built that way.
There are some nice features with distributed systems but I think the best
system to work with would be one that gives some ability to have local
changes and yet KNOWS that it is some part of a hierarchy. It should
KNOW what is "from God/linus"
and what is from the local mortals. Despite what git and mercurial
say, the
two are NOT really equivalent.
> What I'm advocating is the usage experience. Things like:
>
> * Anyone can create a branch, and no one else will be aware of it
> unless they go looking for it, but all branches are peers.
>
> * Checkout, editing, and checkin of directories follows the same
> workflow as files.
>
> * Elements (files, directories) can be moved from one directory to
> another without losing history. The move is initially visible
> only on the branch where it is performed, becoming visible on
> other branches via merging, just as with file edits.
>
> * Graphical visualization of any element's branch and version tree,
> including all merges.
>
> * Automatic identification of the common ancestor ("base contributor")
> version when performing a merge.
>
> * The best multi-way merge tool I have seen -- it has issues, but
> overall I rate it a B+. (I would rate most no higher than a C.)
> The same merge tool is used for directories as for files, with
> directory entries being represented textually.
>
> ----------
>
> [1] Not every client's -- one view server typically supports
> multiple clients, and nothing keeps track of _them_.
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E5C364D.7070904>