Re: [git-users] Git Centralized Architecture

[Ray Joseph]

On Monday, December 14, 2015 at 3:19:07 AM UTC-6, Magnus Therning wrote:
>
>
> Ray Joseph writes: 
> > I would like to see what options there are for the 
> > workspace/repository architecture in an engineering company. 
> > Considerations: 
> > 
> > 1)  400 contributors 
> > 
> > 2)  20 projects on going at any time 
> > 
> > 3)  Contributors are typically on more than one project 
> > 
> > 4)  Artifacts / properties 
> > 
> >a) CAD drawings with no external references 
> > 
> >b) CAD drawings with external references (other drawings, 
> >spreadsheets) 
> > 
> >c) Spreadsheets (some used to drive drawings and datasheets) 
> > 
> >d) Device datasheets 
> > 
> >e) Specifications 
> > 
> >f) Reports 
> > 
> > 5)  We currently have 5 offices across the globe ( 4 in the US). 
>
> I think you first of all have to ask yourself the following question: 
>
> - Why (distributed & concurrent) version control? 
>
> A few answers to the question for SW engineering are: 
>
> 1. We have a need to support multiple released versions of the software 
> concurrently. 
>
> 2. Each member of the team needs to be free to make changes in any file, 
> no matter what other members of the team are working on.  (In other 
> words, develops must be able to make changes to the same file 
> concurrently.) 
>
> 3. We can use version control to help diagnose issues with the code 
> (e.g. `git bisect`). 
>
> There are many more possible answers, but I hope you get the gist by now 
> :) 
>
> Another consideration is also that many of the version control tools 
> that were developed for SW take advantage of source code being plain 
> text (this is almost universally the case).  There are well-know 
> algorithms for diffing and merging plain text.  It looks to me like you 
> are not dealing with plain text files in which case you need to look 
> into diffing and merging of the files you are planning to put into git. 
> (In my experience this is where the value of using a VCS tool for 
> non-text files *really* drop.) 
>
> /M 
>

  

Magnus,

Thank you for the thoughtful response.  While at first I stumble over your 
not answering my question, patience lead me to more carefully consider your 
comments.


The SW approach is significantly different than I am used to in a ‘dumb 
steal’ (DS) engineering environment.  It would be a huge step for just my 
company of 200 users to be swayed be one individual to change their 
fundamental practices; but I am open to great challenges.  


The differences in the two engineering types (SW & DS) are not that great 
and the tools and artifacts are only abstractly equivalent.  Still, my 
fundamental functional challenge is the size of the repository.  Each time 
a repository transaction occurs, work would stop due to the large size (100 
GB).  So I wonder if there is some way to segment or fragment a repository 
so an artifact that needs to be worked can be pulled with only its minimum 
set of related artifacts.  


Ray 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git Centralized Architecture

[Magnus Therning]

Ray Joseph writes:
> I would like to see what options there are for the
> workspace/repository architecture in an engineering company.
> Considerations:
>
> 1)  400 contributors
>
> 2)  20 projects on going at any time
>
> 3)  Contributors are typically on more than one project
>
> 4)  Artifacts / properties
>
>a) CAD drawings with no external references
>
>b) CAD drawings with external references (other drawings,
>spreadsheets)
>
>c) Spreadsheets (some used to drive drawings and datasheets)
>
>d) Device datasheets
>
>e) Specifications
>
>f) Reports
>
> 5)  We currently have 5 offices across the globe ( 4 in the US).

I think you first of all have to ask yourself the following question:

- Why (distributed & concurrent) version control?

A few answers to the question for SW engineering are:

1. We have a need to support multiple released versions of the software
concurrently.

2. Each member of the team needs to be free to make changes in any file,
no matter what other members of the team are working on.  (In other
words, develops must be able to make changes to the same file concurrently.)

3. We can use version control to help diagnose issues with the code
(e.g. `git bisect`).

There are many more possible answers, but I hope you get the gist by now
:)

Another consideration is also that many of the version control tools
that were developed for SW take advantage of source code being plain
text (this is almost universally the case).  There are well-know
algorithms for diffing and merging plain text.  It looks to me like you
are not dealing with plain text files in which case you need to look
into diffing and merging of the files you are planning to put into git.
(In my experience this is where the value of using a VCS tool for
non-text files *really* drop.)

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

Java is, in many ways, C++--.
 -- M Feldman

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[git-users] Git Centralized Architecture

[Ray Joseph]

 

I would like to see what options there are for the workspace/repository 
architecture in an engineering company.Considerations:

1)  400 contributors

2)  20 projects on going at any time

3)  Contributors are typically on more than one project

4)  Artifacts / properties

   a) CAD drawings with no external references

   b) CAD drawings with external references (other drawings, spreadsheets)

   c) Spreadsheets (some used to drive drawings and datasheets)

   d) Device datasheets

   e) Specifications

f) Reports

5)  We currently have 5 offices across the globe ( 4 in the US).

 

Our current workflow (no version management system) includes a centralized 
network.  Each type of artifact shares a folder for common artifacts.  Users 
operate directly on the network share (no files are stored on the users 
machine).  These larage files open rapidly over the network.  The major 
purpose for the network workspace has to do with saving files.  When the 
workspace was on local machines, there were huge difficulties of the wrong 
version being on the network.  Assuring the most up to date files are on 
the network is extremely important.  With a VCS, it would be great that 
everytime a user saved a file, it would be committed and when opening a 
file, the master would be the default.

 

I have just finished reading *https://git-scm.com/book/en/v2* 
.  There seems to be many options, but it 
seems ‘cumbersome’ to checkout and commit when the repository would be 100 
GB.  And more so, in conflict with the checkout overlaying all files on the 
common workspace.  We had setup a SVN test where individual files were 
version controlled.  This allowed for the common workspace and minimal 
interaction since drawings are not readily tested as code (I would really 
like to have an automated method to accomplish that but it would take up 
more time than I have).  

 

Thank you ahead of time for all feedback.

 

Ray

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.