git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Pierre Tardy <tardyp@gmail.com>, Elijah Newren <newren@gmail.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	"peff\@peff.net" <peff@peff.net>,
	Emily Shaffer <emilyshaffer@google.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	"gitster\@pobox.com" <gitster@pobox.com>,
	garimasigit@gmail.com
Subject: Re: [DISCUSSION] Growing the Git community
Date: Fri, 04 Oct 2019 14:39:28 +0200
Message-ID: <86tv8oofb3.fsf@gmail.com> (raw)
In-Reply-To: <1b988670-381b-1c92-069b-3cb66254861c@gmail.com> (Derrick Stolee's message of "Wed, 25 Sep 2019 10:02:16 -0400")

Derrick Stolee <stolee@gmail.com> writes:
> On 9/25/2019 9:36 AM, Pierre Tardy wrote:
[...]
>> And why restrict on DVCS?
>> Isn't it admitted that the distributed version control is nowadays
>> much better in term of software productivity?
>> Is there some use cases that "traditional" centralized VCS are better
>> on, and on which we gave up as a goal?
>
> My intention was "let's be the best at what  Git is good at: distributed
> version control." There are some legitimate reasons why someone would
> pick something like Perforce instead.
>
> Some things, like *file locking*, are just easier in centralized systems.
> I know that Git-LFS created a locking mechanism that pushes even further
> toward a centralized system. However, it relies on users following a
> very careful pattern (lock, pull, edit, push, merge, unlock) to avoid
> conflicts. Further, that only works if you are on a common trunk.
> Release branches or forks do not have this concept.

Well, there is (or perhaps was, as the latest release is from 2013) DVCS
named Veracity that tried to be better than other DVCS in corporate
environment.  It did include file-locking:
  http://veracity-scm.com/
  https://ericsink.com/vcbe/html/veracity_locks.html


But perhaps there would be a better solution to handling file types that
do not support conflict resolution at all than file-level locks: see the
“Git for games: current problems and solutions” presentation by John
Austin at Git Merge 2019:
  https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=8&t=0s

Though the tool mentioned here had not seen any significant development
since Feb 1, 2019 (well, at least in the public repo at GitHub).

From Git Rev News: Edition 48 (February 27th, 2019)
  https://git.github.io/rev_news/2019/02/27/edition-48/

GR> John Austin, game studio technical lead from A Stranger Gravity and
GR> Funomena in “Git for games: current problems and solutions” talked
GR> about major problem with using Git in game development workflows,
GR> namely many and large binary files, for which file conflicts are
GR> lost work (minor change, like adding voiceover or changing equalizer
GR> settings results in large changes to files). File locking is one
GR> possibility, but it doesn’t play nicely with Git – it is inherently
GR> centralized. He introduces a new tool, [Git Global Graph][1] (a work in
GR> progress), which can be used to check at commit time if it wouldn’t
GR> create a divergent version of a file. The idea is that there should
GR> be only a single path through commit graph with changes to binary
GR> files.

[1]: https://github.com/Kleptine/gitglobalgraph


Best,
-- 
Jakub Narębski

  reply	other threads:[~2019-10-04 12:39 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 16:30 Derrick Stolee
2019-09-19 17:34 ` Denton Liu
2019-09-19 20:43   ` Emily Shaffer
2019-09-19 22:26   ` Jeff King
2019-09-20 17:48     ` Junio C Hamano
2019-09-20 15:22   ` Garima Singh
2019-09-20 17:51     ` Junio C Hamano
2019-09-19 18:44 ` Klaus Sembritzki
2019-09-19 19:12   ` Klaus Sembritzki
2019-09-19 20:20     ` Klaus Sembritzki
2019-09-20  5:04       ` Klaus Sembritzki
2019-09-20  5:41         ` Klaus Sembritzki
2019-09-20  6:54           ` Klaus Sembritzki
2019-09-20  7:43             ` Klaus Sembritzki
2019-09-20 10:25               ` Klaus Sembritzki
2019-09-19 21:40 ` Mike Hommey
2019-09-23 21:28   ` Johannes Schindelin
2019-10-01 15:03     ` Jakub Narebski
2019-09-19 22:16 ` Jeff King
2019-09-20  2:17   ` Derrick Stolee
2019-09-20  2:23     ` Jeff King
2019-09-19 22:21 ` Elijah Newren
2019-09-25 13:36   ` Pierre Tardy
2019-09-25 14:02     ` Derrick Stolee
2019-10-04 12:39       ` Jakub Narebski [this message]
2019-09-25 14:14     ` Philip Oakley
2019-10-04 10:48   ` Jakub Narebski
2019-11-12 18:45   ` Emily Shaffer
2019-11-12 20:01     ` Johannes Schindelin
2019-11-13  6:45       ` Christian Couder
2019-11-13 15:06         ` Thomas Gummerer
2019-11-14  2:31           ` Emily Shaffer
2019-11-14  6:06             ` Jeff King
2019-11-15  4:48               ` Junio C Hamano
2019-11-14  6:08             ` Pratyush Yadav
2019-11-14 10:01               ` Thomas Gummerer
2019-09-20 10:48 ` Philip Oakley
2019-09-20 14:36 ` brian m. carlson
2019-09-20 15:16   ` Randall S. Becker
2019-10-04 14:27   ` Jakub Narebski
2019-09-20 15:20 ` Garima Singh
2019-09-20 17:43 ` Junio C Hamano
2019-09-20 18:52   ` Junio C Hamano
2019-09-23 12:36 ` Derrick Stolee
2019-09-23 21:46 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86tv8oofb3.fsf@gmail.com \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=garimasigit@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=stolee@gmail.com \
    --cc=tardyp@gmail.com \
    --subject='Re: [DISCUSSION] Growing the Git community' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git