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 



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 

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.  


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.

Reply via email to