Official git export

Julian Elischer julian at freebsd.org
Tue Aug 30 01:05:07 UTC 2011


On 8/29/11 8:39 PM, perryh at pluto.rain.com wrote:
> Philip Paeps<philip at freebsd.org>  wrote:
>> On 29 Aug 2011, at 17:01, perryh at pluto.rain.com wrote:
>>> Vadim Goncharov<vadim_nuclight at 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.)
>
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>



More information about the freebsd-arch mailing list