| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: AreaDetector repository inconsistent |
| From: | Kevin Peterson <[email protected]> |
| To: | Mark Rivers <[email protected]> |
| Cc: | "[email protected]" <[email protected]> |
| Date: | Wed, 7 Feb 2018 13:14:58 -0600 (CST) |
On Wed, 7 Feb 2018, Mark Rivers wrote:
Ø I like the certainty of using tar files of released versions in most cases, and explicitly deployed git clones in a beamline's local file tree if it's required. I think “git checkout R3-4” is as certain as getting the R3-4 tar file. The advantage of the git clone is that you can immediately see if someone has changed a file with “git diff R3-4”. If you have a tar file, and someone has changed a .template file, etc. you have no easy way tell.
The advantages and disadvantages of this depend on the deployment and maintenance strategy.
The BCDA currently uses subversion to track changes to most deployed modules, so being able to use git to see changes to deployed files provides little additional value. If we didn't already have a system, this would be a useful feature, though I would create a local "deployed" branch rather than run from the master, to minimize damage from accidental pushes.
If only one person is deploying and maintaining EPICS modules, running from a github clone for every module isn't a problem. If many people support EPICS modules and IOCs, the overhead of having to navigate to each EPICS module to type "git branch" to find out what versions of software an IOC is running is very painful and time consuming.
Kevin