git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Konstantin Khomoutov <kostix@bswap.ru>
To: David Hind <David.Hind@dynexsemi.com>
Cc: git@vger.kernel.org
Subject: Re: Using Git for applications other than code development
Date: Wed, 25 Jul 2018 17:48:26 +0300	[thread overview]
Message-ID: <20180725144826.wznifhnrahav6tdv@tigra> (raw)
In-Reply-To: <4b9575bf039e46cd9dc150111916e734@LINCEXCHANGE1.dynexsemi.com>

On Wed, Jul 25, 2018 at 01:02:16PM +0000, David Hind wrote:

> I work for a company that is looking to adopt VCS and I like sound of
> Git (although I have no experience of using VCS). My question is,
> everything seems to be directed towards code developers. Can I use Git
> to do revision control for other types of design document? For example
> electrical circuit designs, circuit PCB designs etc.?

In addition to what Randall said (I would affirm he has presented a
comprehensive and correct picture), I'd make one minor note: Git is a
distributed VCS, and this requires certain pondering.

Even though you will almost certainly have one central (also
colloquially called "rendez-vouz") repository where everyone pushes
their changes to, and fetches them from, Git allows recording any number
of so-called "commits" — atomic, from a logical standpoint, changes to
the project — before sharing them with the rest of the team.

For software development, this _is_ blessing; for other kinds of
development it may be not so good — with the need to somehow resolve
possible conflicts in series of changes made in parallel by multiple
developers to the same content being supposedly the main impediment.
With software development it's simple: it's still done by writing
textual files (even tools which generate code automatically tend to
generate something textual these days), and conflicts in textual files
are relatively easy to represent (even without resorting to specialized
tools). Now, say, let's look at gamedev where a part of the team are
artists which work on "assets" — such as 3D-models and textures.
Two conflicting changes in the same texture are harder to reconcile.

Some (most?) centralized VCSes (as opposed to distibuted) support
explicit "locking" of certain files - which works like sort of claim
"I'm working on this file, don't touch it". Git does not have locking,
and if you think it may benefit your workflow then may be other options
might suite you better.


      parent reply	other threads:[~2018-07-25 14:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 13:02 Using Git for applications other than code development David Hind
2018-07-25 13:31 ` Randall S. Becker
2018-07-25 14:48 ` Konstantin Khomoutov [this message]

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=20180725144826.wznifhnrahav6tdv@tigra \
    --to=kostix@bswap.ru \
    --cc=David.Hind@dynexsemi.com \
    --cc=git@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).