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