Enterprise Level Version Control Git
Hello all,
I routinely use git for my programming - and there are obvious advantages of been able to use such a system at work. I have mentioned it to one of our senior managers, and he is keen to have a look. I am hoping we can implement it corporate wide at some stage.
Is there anyone out there that has experience in either using git at enterprise level, or even better has had experience with implementing such as system in a corporate environment? Our company uses Windows exclusively. We would definitely need GUI software - there are plenty of those, but which one might be best?
So far I have said to start with baby steps, just have a go with 1 or maybe 3 users, with 1 directory worth of files, with the idea of seeing what the advantages are. Also, we could try different software at this point.
Once we are happy with that, I imagine we could expand that, we have one site with 4 users, and their files are on a separate NAS (Network Attached Storage) box. The fact it is a small amount of users, and being separate are important factors, at that stage.
I can see that education & training are going to be really important in implementing on this kind of larger scale.
Some information about our company:
We have 300+ staff with 5 offices around Australia, plus some people in Papua New Guinea and Singapore. Each office has it's own server, some of the larger jobs have their own NAS box, some jobs have their files on a clients server.
There are various types of work we do, from traditional survey (Land Development, Construction, Mining etc.), to Laser Scanning and UAV aerial photography. Also, there is the corporate stuff, like HSEQ (Health Safety Environment & Quality) and other Policy type things, to Business Development Management, and Accounting.
Anyway, I look forward to any advice that anyone has. Cheers :+)
I routinely use git for my programming - and there are obvious advantages of been able to use such a system at work. I have mentioned it to one of our senior managers, and he is keen to have a look. I am hoping we can implement it corporate wide at some stage.
Is there anyone out there that has experience in either using git at enterprise level, or even better has had experience with implementing such as system in a corporate environment? Our company uses Windows exclusively. We would definitely need GUI software - there are plenty of those, but which one might be best?
So far I have said to start with baby steps, just have a go with 1 or maybe 3 users, with 1 directory worth of files, with the idea of seeing what the advantages are. Also, we could try different software at this point.
Once we are happy with that, I imagine we could expand that, we have one site with 4 users, and their files are on a separate NAS (Network Attached Storage) box. The fact it is a small amount of users, and being separate are important factors, at that stage.
I can see that education & training are going to be really important in implementing on this kind of larger scale.
Some information about our company:
We have 300+ staff with 5 offices around Australia, plus some people in Papua New Guinea and Singapore. Each office has it's own server, some of the larger jobs have their own NAS box, some jobs have their files on a clients server.
There are various types of work we do, from traditional survey (Land Development, Construction, Mining etc.), to Laser Scanning and UAV aerial photography. Also, there is the corporate stuff, like HSEQ (Health Safety Environment & Quality) and other Policy type things, to Business Development Management, and Accounting.
Anyway, I look forward to any advice that anyone has. Cheers :+)
Last edited on
We switched from SVN to Git at the last place I worked. It was pretty painless for most people, though the need to stage (commit) before pushing confused a few who were so acclimatised to the way SVN worked (they mislaid changes as they pushed and pulled without staging their changes.)
The Windows-based teams used TortoiseGit (a logical choice as we were previously using TortoiseSVN) for routine operations. There are some things it's easier to deal with on the command line and were scripted (using Python).
One thing we did before moving from SVN to Git is review our branching stragegy.
Switching the build server to work with Git rather than SVN wasn't too much of a trauma, either.
Andy
The Windows-based teams used TortoiseGit (a logical choice as we were previously using TortoiseSVN) for routine operations. There are some things it's easier to deal with on the command line and were scripted (using Python).
One thing we did before moving from SVN to Git is review our branching stragegy.
Switching the build server to work with Git rather than SVN wasn't too much of a trauma, either.
Andy
Last edited on
Hi Andy,
Thanks for your reply :+)
We are in the interesting position in that no one except me knows what version control is, and that I first mentioned it to management yesterday ........ :+D I also need to have a good look at a GUI software - I have only ever used it from a plug-in from my IDE.
I can see from your experience that training, education & strategy are important, I imagine we will have to do that in depth. Even though the concept is pretty easy in our minds, I am hoping our users will see the benefits and overcome their fear of doing something new or extra.
I hope that I am going about this the right way: looking at all the options; and starting out small, then gradually get bigger.
If anyone else has had some experience, please feel to post - I look forward to your replies :+)
Thanks for your reply :+)
We are in the interesting position in that no one except me knows what version control is, and that I first mentioned it to management yesterday ........ :+D I also need to have a good look at a GUI software - I have only ever used it from a plug-in from my IDE.
I can see from your experience that training, education & strategy are important, I imagine we will have to do that in depth. Even though the concept is pretty easy in our minds, I am hoping our users will see the benefits and overcome their fear of doing something new or extra.
I hope that I am going about this the right way: looking at all the options; and starting out small, then gradually get bigger.
If anyone else has had some experience, please feel to post - I look forward to your replies :+)
If you're not using any version control now, then it's a no brainier. I would have everyone start using git or mercurial immediately.
I have used the git gui, Source Tree, in the past, and it seams ok. Now I am using the Git Basch command prompt, on windows, which I like more because, using it, I know exactly what I'm doing, and I think it's easier to learn to understand that way. With the GUI's, you tend to not actually learn GIT or how it works, because the commands and their precise effects are abstracted from you.
I have used the git gui, Source Tree, in the past, and it seams ok. Now I am using the Git Basch command prompt, on windows, which I like more because, using it, I know exactly what I'm doing, and I think it's easier to learn to understand that way. With the GUI's, you tend to not actually learn GIT or how it works, because the commands and their precise effects are abstracted from you.
Last edited on
| no one except me knows what version control is |
No version control at all for the software your company writes? But do you use source diff tools?
We did get some training on Git, but everyone involved had experience of other SCM systems. So we just need a couple of training sessions (an hour or so each) to cover the differences between the new and old tool.
Andy
Haven't personally had any experience with importing git into Enterprise level software but just thought I would post my recommendation for a good git/mercurial GUI since you are looking for one.
From all that I have tried for Windows SourceTree is hands down the best one out there in my opinion https://www.sourcetreeapp.com/ . Very easy to learn and use, even for people will little to no experience with version control (Though might require a bit of setup from someone more experienced). Comes with some really nice features also for both beginners and advance users alike (Gitflow integration).
Also another plus is that it is currently owned by Atlassian so provides some nice integration with their other apps that are geared toward enterprise level projects. https://www.atlassian.com/
From all that I have tried for Windows SourceTree is hands down the best one out there in my opinion https://www.sourcetreeapp.com/ . Very easy to learn and use, even for people will little to no experience with version control (Though might require a bit of setup from someone more experienced). Comes with some really nice features also for both beginners and advance users alike (Gitflow integration).
Also another plus is that it is currently owned by Atlassian so provides some nice integration with their other apps that are geared toward enterprise level projects. https://www.atlassian.com/
The company I just started working at migrated from SVN + their own SCM system to Git. They use GitHub Enterprise and it seems to work great there. Roughly 21,000 employees, a large percentage of that is developers. Offices all over the world.
As far as tools, they let their employees use whatever they'd like. Some IDEs have decent integration, but it seems a lot of people just use SourceTree or git from a command line.
As far as tools, they let their employees use whatever they'd like. Some IDEs have decent integration, but it seems a lot of people just use SourceTree or git from a command line.
Thanks everyone for their advice - cheers :+D
I will add SourceTree, GitHub Enterprise to the list of software to evaluate.
Ha - I wish I could be employed writing software, alas (as I mentioned in my first post) we do Land Surveying. My first sentence was misleading - I meant that I use Git for my personal programming - my actual work is completely different :+)
Well I would love for everyone to take that on board and enjoy using it, however I have a somewhat pessimistic outlook on how the average employee might view something new & different or that involves even a minuscule amount of extra work or something to learn. I have come across people that have a Masters Degree, and will come straight out and say "that's too complicated" . Hopefully people like that will be in the minority, but there are still lots of issues implementing what seems a trivial thing into a corporate business, even when people are keen to get started.
First up, for people that write code, VC (Version Control) is such a trivial thing we all use it - just like breathing, and not using it is an alien thing. Even using the command line takes an extra 2 or 3 brain cells. But now visualise the average employee - if they can't click it with the mouse - then they don't want to have anything to do with it.
Next, if one is going to use VC, then it has to used by everyone that has access to files that are under VC. Obviously we can't have people editing files directly in directory that is under VC.
Now I had better explain what I mean by using Git with other software. If we are talking about ASCII files, then things are really easy in terms of all the normal VC actions. When the file is a MS Word or Excel file, then I guess there will need to be a plug-in, so that the user can do their Git from within the software (I might be wrong about this). That is what I do when using QtCreator - the plug-in does the Git commands, but does the Git-GUI have better functionality ? I am hoping that the Git-GUI allows browsing through the file system, and open files (with the right Git version) in the same way that MS Explorer does. Some programs, like MS Word has facilities to show which edits were by which users, this will get a lot of use by people who write Policy documents. I guess for other file formats (like AutoCAD ) one will have to rely on the log files for a description of who did what - which is fine.
We do have some Survey Software called 12D, which works in a different way to other software, and this software is used by a lot of our Surveyors. Normally a user runs the software program itself, this displays a Dialogue that has Job management functions in it, the user selects the job that they want and the software goes to the appropriate directory and opens the job file. The Job has models (aka Layers in AutoCAD parlance) , these models each have a file of their own. The names of the models and other resources like fonts etc are stored in the job file, and the software opens these files as required. How does Git handle the situation where a model is edited?
@Zereo & ResidentBiscuit
Thanks heaps, I will look into your suggestions :+)
Thanks to all for their time, I still look forward to any further comments. Hopefully you all are having a great weekend :+)
I will add SourceTree, GitHub Enterprise to the list of software to evaluate.
| andywestken wrote: |
|---|
| No version control at all for the software your company writes? But do you use source diff tools? |
Ha - I wish I could be employed writing software, alas (as I mentioned in my first post) we do Land Surveying. My first sentence was misleading - I meant that I use Git for my personal programming - my actual work is completely different :+)
| htirwin wrote: |
|---|
| If you're not using any version control now, then it's a no brainier. I would have everyone start using git or mercurial immediately. |
Well I would love for everyone to take that on board and enjoy using it, however I have a somewhat pessimistic outlook on how the average employee might view something new & different or that involves even a minuscule amount of extra work or something to learn. I have come across people that have a Masters Degree, and will come straight out and say "that's too complicated" . Hopefully people like that will be in the minority, but there are still lots of issues implementing what seems a trivial thing into a corporate business, even when people are keen to get started.
First up, for people that write code, VC (Version Control) is such a trivial thing we all use it - just like breathing, and not using it is an alien thing. Even using the command line takes an extra 2 or 3 brain cells. But now visualise the average employee - if they can't click it with the mouse - then they don't want to have anything to do with it.
Next, if one is going to use VC, then it has to used by everyone that has access to files that are under VC. Obviously we can't have people editing files directly in directory that is under VC.
Now I had better explain what I mean by using Git with other software. If we are talking about ASCII files, then things are really easy in terms of all the normal VC actions. When the file is a MS Word or Excel file, then I guess there will need to be a plug-in, so that the user can do their Git from within the software (I might be wrong about this). That is what I do when using QtCreator - the plug-in does the Git commands, but does the Git-GUI have better functionality ? I am hoping that the Git-GUI allows browsing through the file system, and open files (with the right Git version) in the same way that MS Explorer does. Some programs, like MS Word has facilities to show which edits were by which users, this will get a lot of use by people who write Policy documents. I guess for other file formats (like AutoCAD ) one will have to rely on the log files for a description of who did what - which is fine.
We do have some Survey Software called 12D, which works in a different way to other software, and this software is used by a lot of our Surveyors. Normally a user runs the software program itself, this displays a Dialogue that has Job management functions in it, the user selects the job that they want and the software goes to the appropriate directory and opens the job file. The Job has models (aka Layers in AutoCAD parlance) , these models each have a file of their own. The names of the models and other resources like fonts etc are stored in the job file, and the software opens these files as required. How does Git handle the situation where a model is edited?
@Zereo & ResidentBiscuit
Thanks heaps, I will look into your suggestions :+)
Thanks to all for their time, I still look forward to any further comments. Hopefully you all are having a great weekend :+)
If you aren't using version control then your managers are idiots. Seriously. If you can't get them on board, and if they can't get the employees on board then you need to find another job with a real development organization. If they can't get this right then I seriously doubt that they're getting anything else right either.
@dhayden
Hi,
Thanks for your reply :+)
Well I have been working in the Land Surveying Industry for 30 years now, and have never heard of anyone using VC for Surveying. Come to think of it, I haven't heard of anyone else I know using it in their jobs either - and that is across a wide variety of industries.
So, in Australia at least, what I am proposing could be seen as quite a new thing.
Our managers are quite amenable to new ideas, but I guess like anything they want to be sure that it will be worthwhile. As I mentioned earlier, Change Management does have it issues - hopefully for this one they will be minor. As far as employees go, I am sure that if management says we have to use it, then we will. Obviously there might be a need for some education & training, so that people actually know what they are doing.
In terms of our company, we do have quality management - our company is considered one of the top survey companies in Australia. We do work on multi-billion dollar projects and work directly for First Tier Contractors. Our current large project is the Icthys Gas Plant in Darwin, that is a $34bn project.
Any way, I will have to see how I go with Management :+)
Hi,
Thanks for your reply :+)
Well I have been working in the Land Surveying Industry for 30 years now, and have never heard of anyone using VC for Surveying. Come to think of it, I haven't heard of anyone else I know using it in their jobs either - and that is across a wide variety of industries.
So, in Australia at least, what I am proposing could be seen as quite a new thing.
Our managers are quite amenable to new ideas, but I guess like anything they want to be sure that it will be worthwhile. As I mentioned earlier, Change Management does have it issues - hopefully for this one they will be minor. As far as employees go, I am sure that if management says we have to use it, then we will. Obviously there might be a need for some education & training, so that people actually know what they are doing.
In terms of our company, we do have quality management - our company is considered one of the top survey companies in Australia. We do work on multi-billion dollar projects and work directly for First Tier Contractors. Our current large project is the Icthys Gas Plant in Darwin, that is a $34bn project.
Any way, I will have to see how I go with Management :+)
It would have probably been a good idea to put that little bit of information in the OP. I had assumed exactly what dhayden said, that you people were barking mad.
TheIdeasMan, can you explain in more detail just what they want to put under version control? I assumed that you were talking about the source code for computer programs that run your business, or that compile into the software that you sell. In cases like that, it's absolutely essential to keep the code under version control. But I suspect you're talking about something different, like the surveys themselves.
Thanks.
Thanks.
| dhayden wrote: |
|---|
| But I suspect you're talking about something different, like the surveys themselves. |
Hi,
Yes, all our survey information would be great, but also things like policy documents - as in Health & Safety Procedures, Tenders & other Business Development documents to give just a couple of examples. Ideally nearly all the files across the whole business. I imagine we would exclude major databases, such as the system we use for invoicing & employee pay etc.
Our Survey jobs have various types of files, I am fairly confident that most of them would travel quite well under Git. Although for some of them (like the 12D files mentioned earlier), Git might be useful at the directory level - who added what file and when. I suspect that any VC system might not handle such inter-dependency across multiple files. I might be wrong about that though.
As far developing software goes, our business doesn't do any of that, but I fully understand how important VC for developing is. I use Git for my personal programming all the time.
So at this early stage, we are trying out a few different Git-GUI programs - just to see what they are like, and how well they might work for us.
Just to clear things up for everyone, I did have this in my OP(although the edit time was after Andy replied, I thought that I had done a minor edit):
| TheIdeasMan wrote: |
|---|
| There are various types of work we do, from traditional survey (Land Development, Construction, Mining etc.), to Laser Scanning and UAV aerial photography. Also, there is the corporate stuff, like HSEQ (Health Safety Environment & Quality) and other Policy type things, to Business Development Management, and Accounting. |
Also, here is a link to a company that does similar work to us. Note I don't work for this company. I am reluctant to give away too much personal information on the web, so that is the reason I have mentioned another company.
| http://www.aamgroup.com/ |
| Yes, all our survey information would be great, but also things like policy documents - as in Health & Safety Procedures, Tenders & other Business Development documents to give just a couple of examples. Ideally nearly all the files across the whole business. |
Also, Git doesn't do diffs for binary files. Syncing across a slow network get old quickly when you're working in a software project and people keep pushing builds to the central repository after each change.
| I imagine we would exclude major databases, such as the system we use for invoicing & employee pay etc. |
| Just to clear things up for everyone, I did have this in my OP(although the edit time was after Andy replied, I thought that I had done a minor edit): >There are various types of work we do, from traditional survey (Land Development, Construction, Mining >etc.), to Laser Scanning and UAV aerial photography. Also, there is the corporate stuff, like HSEQ (Health >Safety Environment & Quality) and other Policy type things, to Business Development Management, and >Accounting. |
Last edited on
I would be careful trying to get non-programmers to use something like git, unless it solves some problem everyone currently has. I expect most people will just find it annoying, will avoid using it as much as possible. Meanwhile everyone will blame you. I've even heard of, on other forums, a physicist who does programming, quitting because he developed such a hatred for git.
@helios
Thanks for your reply, that sort of info is very useful. If Git is not going to handle MS Office or AutoCAD files, then that will be a game breaker, and is probably the reason why I haven't seen anyone else in this industry doing VC.
Although, if we could have just Versioning, then that would be fine. I was thinking that if we could go back to previous version of an AutoCAD, or Excel file - then that would be a definite improvement. With PDF's, we wouldn't need VC for them, because each revision sent to the client is kept as a separate file. I know that is counter to one of the purposes of using VC, but I guess that's how it will run until everyone is 100% with it. With MS Word, I was going to make use of the functionality in Word to see who did what editing.
The other thing is that we don't have lots of people editing 1 file. Some of our construction projects might have up to 20 guys adding entire files to directories, so i was thinking VC at the directory level would be fine. In that situation there is a local NAS box, so connections aren't slow. For the files that are edited by multiple people, those are ASCII files - typically a CSV file which holds the co-ordinates for Survey Control Stations. Another example might be TXT files which hold the raw observations for a survey.
What we do have is 1 Author of a file, with hundreds wanting to view the latest version (or at least know they are reading the latest). An example might be our HSEQ manger writing Safety Policy Documents.
I will have to look into rsync & versioning though. I will mention all this to my manager.
With our RDBMS, they are fully catered for in terms of backups etc, and are best left well alone. We do have people responsible for the Network & Backups etc.
Cheers :+D
@htirwin
Yes, I was worried about that, and was dreading the exact situation you mentioned. Thanks for your post, you are on the list of people who I always look forward to what you have to say. :+)
Another general concern I have is - cost. Funny that :+) Sure there are free versions of Git GUI programs, but we ethically shouldn't be using those for commercial purposes with 300 users. However, I was looking a GitHub Enterprise and at $65,000 p/a in fees - I know that it will take management 2 nano-seconds to make a negative decision in that respect. Anyone know any tricks for be able to justify that kind of expense? I know that there is no problem in spending $100,000 or more on new scanning equipment, but I have a sneaking suspicion that that sort of argument will fall on deaf ears.
So any more comments are still welcome, I hope everyone is having another good weekend.
Thanks for your reply, that sort of info is very useful. If Git is not going to handle MS Office or AutoCAD files, then that will be a game breaker, and is probably the reason why I haven't seen anyone else in this industry doing VC.
Although, if we could have just Versioning, then that would be fine. I was thinking that if we could go back to previous version of an AutoCAD, or Excel file - then that would be a definite improvement. With PDF's, we wouldn't need VC for them, because each revision sent to the client is kept as a separate file. I know that is counter to one of the purposes of using VC, but I guess that's how it will run until everyone is 100% with it. With MS Word, I was going to make use of the functionality in Word to see who did what editing.
The other thing is that we don't have lots of people editing 1 file. Some of our construction projects might have up to 20 guys adding entire files to directories, so i was thinking VC at the directory level would be fine. In that situation there is a local NAS box, so connections aren't slow. For the files that are edited by multiple people, those are ASCII files - typically a CSV file which holds the co-ordinates for Survey Control Stations. Another example might be TXT files which hold the raw observations for a survey.
What we do have is 1 Author of a file, with hundreds wanting to view the latest version (or at least know they are reading the latest). An example might be our HSEQ manger writing Safety Policy Documents.
I will have to look into rsync & versioning though. I will mention all this to my manager.
With our RDBMS, they are fully catered for in terms of backups etc, and are best left well alone. We do have people responsible for the Network & Backups etc.
Cheers :+D
@htirwin
Yes, I was worried about that, and was dreading the exact situation you mentioned. Thanks for your post, you are on the list of people who I always look forward to what you have to say. :+)
Another general concern I have is - cost. Funny that :+) Sure there are free versions of Git GUI programs, but we ethically shouldn't be using those for commercial purposes with 300 users. However, I was looking a GitHub Enterprise and at $65,000 p/a in fees - I know that it will take management 2 nano-seconds to make a negative decision in that respect. Anyone know any tricks for be able to justify that kind of expense? I know that there is no problem in spending $100,000 or more on new scanning equipment, but I have a sneaking suspicion that that sort of argument will fall on deaf ears.
So any more comments are still welcome, I hope everyone is having another good weekend.
| For the files that are edited by multiple people, those are ASCII files - typically a CSV file which holds the co-ordinates for Survey Control Stations. Another example might be TXT files which hold the raw observations for a survey. |
An automated backup system in each computer that does daily backups when no one's using the system and puts them in a directory in the NAS sounds like a more fitting solution to me.
| helios wrote: |
|---|
| What's your workflow like with those? Git could help there, but if you already have a workflow that prevents screw-ups, it could just be an annoyance. |
Well there doesn't seem to be any set procedure for all jobs (they vary as to what the job type / purpose is, or don't exist at all), apart from files names are suppose to start with a reversed date (150628), but even that is not guaranteed. Various people seem to do various things on some jobs. On other jobs there is a definite naming system for directories and files, the whole thing is pretty well organised.
With our jobs, we have a handful of large jobs, then hundreds of very small jobs. The larger ones are very well organised, but for the smaller ones, it depends on who is doing it. This is an issue that management is aware of, and is looking to do something about it.
So I think that VC will help quite a bit. For example we could have a rule that there is only 1 Control File (Control Station Names & Co-ordinates), not multiple files with different dates, nor partial files (A particular area say)
For the ASCII files, it will be a definite advantage to be able to look at the diff files.
Thanks again for your reply :+)
So you coordinate edits to a single file by splitting it into bits that each person will edit at will and then do one big merge at the end of the project, and do versioning by simple copy-pasting, right? I can see Git being of use in that scenario.
What you do in a software project is, you split your team into manageable groups (if the team is small there may be a single group), and each group has a single developer that merges the changes of the other developers into his/her branch. If there are several groups, one of the merger developers will merge the branches of the other merger developers into his/her branch. And so on until you have a full hierarchical tree. This arrangement minimizes conflicts, because only one developer modifies any branch at any time. In case of merge conflicts, typically the owner of the branch that is being merged has the responsibility of resolving the conflict. For example:
1. Developer A branches Branch A from Branch C.
2. Developer B branches Branch B from Branch C.
3. Both developers work in their branches.
4. Developer C merges Branch B into Branch C.
5. Developer C tries to merge Branch A into Branch C. If there are no conflicts, go to step 10.
6. Developer C notifies Developer A of the conflicts.
7. Developer A merges Branch C into Branch A, resolving any conflicts.
8. Developer A notifies Developer C of the resolution.
9. Go to step 5.
10. Done.
What you do in a software project is, you split your team into manageable groups (if the team is small there may be a single group), and each group has a single developer that merges the changes of the other developers into his/her branch. If there are several groups, one of the merger developers will merge the branches of the other merger developers into his/her branch. And so on until you have a full hierarchical tree. This arrangement minimizes conflicts, because only one developer modifies any branch at any time. In case of merge conflicts, typically the owner of the branch that is being merged has the responsibility of resolving the conflict. For example:
1. Developer A branches Branch A from Branch C.
2. Developer B branches Branch B from Branch C.
3. Both developers work in their branches.
4. Developer C merges Branch B into Branch C.
5. Developer C tries to merge Branch A into Branch C. If there are no conflicts, go to step 10.
6. Developer C notifies Developer A of the conflicts.
7. Developer A merges Branch C into Branch A, resolving any conflicts.
8. Developer A notifies Developer C of the resolution.
9. Go to step 5.
10. Done.
| helios wrote: |
|---|
| So you coordinate edits to a single file by splitting it into bits that each person will edit at will and then do one big merge at the end of the project, and do versioning by simple copy-pasting, right? |
Not really. A surveyor goes to site and measures a bunch of new control stations for Area A. Instead of saving them into the control file for the whole site, s/he saves it as 150628AreaAControl.csv, which is bad practice. If there was 1 control file for the whole site, and everyone used it exclusively, we could use Git to see who added / deleted what & when, and the best part - one can be confident that one has the latest version. Deletions happen because control marks are sometimes destroyed by Earth Moving equipment. Having 1 file under Git, is better than having 20 files with different dates, even though each of those files contain all the control info for the whole site at different times.
Another example is where a surveyor saves the observations for a survey into a TXT file. Sometimes there is a need to edit this file, so a copy is made with a new date in the name. If it is a junior doing this, then it is very handy to look at a diff file to see exactly what was changed.
It is for reasons like this that I am trying to promote the use of Git.
I understand what you are saying about merging & branching, but for our ASCII files at least, we probably won't have a need for that - simple VC will be fine. Where merging & branching would be useful is with Policy documents which will be MS Word files, as discussed earlier Git won't work so well with those for that purpose. An example of the sort of document could be specification of requirements for doing road surveys. Two thirds of the document might be common, but each State might have variations for local practices or regulations.
I hope that you know that by co-ordinates I mean XYZ coordinates. That might seem a silly question - I don't mean to insult your intelligence, but it was the way you worded "So you coordinate edits to a single file ... " It's just that there has been confusion already, I am trying to possibly prevent any more. :+)
Regards
Topic archived. No new replies allowed.