From owner-freebsd-arch@FreeBSD.ORG Tue Aug 30 01:05:07 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA366106566B for ; Tue, 30 Aug 2011 01:05:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B92418FC12 for ; Tue, 30 Aug 2011 01:05:06 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p7U154rc051022 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Aug 2011 18:05:05 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E5C3753.9020001@freebsd.org> Date: Mon, 29 Aug 2011 18:05:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> In-Reply-To: <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-arch@freebsd.org, philip@freebsd.org Subject: Re: Official git export X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:05:07 -0000 On 8/29/11 8:39 PM, perryh@pluto.rain.com wrote: > Philip Paeps wrote: >> On 29 Aug 2011, at 17:01, perryh@pluto.rain.com wrote: >>> Vadim Goncharov 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.) > > 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. not all branches are peers. That's just the way things are in the real world. what follows could be a description of many VCS. > * 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. p4 can do this really well... a lot of DSCS can't. > * 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. ***** I once had to work with clearcase... I swore to never do so again. Never trust a system to hold your files when you can't find where the y really are. (as a user) *** > ---------- > > [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" >