Experimental Physics and
Industrial Control System

Jeong Han Lee via Core-talk <[email protected]> · Wed, 30 Jan 2019 23:40:46 +0100

Hi Andrew,

Those submodule branches were merged back into the main (7.0) branch in October, and we tagged the end of each branch as a record of the last commit on it, but we didn’t want to confuse people in the future so we removed the branches themselves. They are easy to recreate in git if someone needs them though, see below.

 I think, I am fine now. Still BASE 7.0.1.1 is not the official product

at ESS. I will ask other people who would like to see how it works in

order to use 7.0.2 instead of 7.0.1.1. Please ignore my email.

  Is there any other reason why we changed its tags? Without these tags, R7.0.1.1 has no meaning either.

We didn’t actually change tags at all, but GitHub probably doesn’t understand exactly what we did so the view you have through it doesn’t quite match what happened.

Can we recover their branches? We are now using R7.0.1.1 as the test platform for BASE 7 at ESS, because we cannot use 7.0.2 due to int64 record.

The int64 record types were present in R7.0.1.1, so I don’t quite understand that as a reason but no matter...

 Yes, but without recent fixed

https://github.com/epics-base/pva2pva/issues/25#issuecomment-452429849,

we cannot access int64 record.

  I am waiting for patch files or 7.0.3 release.

The commits on those branches still exist safely within the git history for epics-base, and you can re-create them by checking out the SHA that GitHub shows for the submodules. There was also a tag created for each submodule at 7.0.1 release time: libcom-3.17.0 ca-4.13.1 and database-3.17.0. Thus you should be able to recreate a git working tree with the submodules at the time of the R7.0.1.1 tag as follows:

git clone -b R7.0.1.1 https://github.com/epics-base/epics-base.git base-7.0.1.1
git submodule update —init

The result should agree with this, which is what I got doing that:

woz$ git submodule status
  524ceee2c8ce8f8446c46d93b5a467edd14b8cc5 modules/ca (ca-4.13.1)
  610f008529059c7fc1e35896ff0f678b7adcfa6d modules/database (database-3.17.0)
  8ce980f6637d85fb1f5a139bab404269734b31bc modules/libcom (libcom-3.17.0)
  ba2e1c8a1d1837c8817e14372cccc12f16942200 modules/normativeTypes (5.2.0)
  8c4353bd57dc4e29145792b2b6e2aeeb81c32efe modules/pvAccess (6.0.0)
  07afe3887bc4d6ca921d135eef13d91c9e84a155 modules/pvData (7.0.0)
  b26c0ecd713a9c87b891afbfef44d6109e13800a modules/pvDatabase (4.3.0)
  40014786810c3709c0e14cb179c93cdcfb66f973 modules/pva2pva (1.0.0)
  b5291d96196825fd2ce5d7ce47559b1dddf3449e modules/pvaClient (4.3.0)

Now everything there is checked out in a detached head state, but that’s what a checkout out of a tag means anyway.

 Not quite true, and interesting enough, I am using ssh instead of

http in order to clone them. Then I've got the following errors:

 fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

fatal: clone of 'https://github.com/epics-base/epics-base.git/' into

submodule path '/home/jhlee/base-7.0.1.1/modules/ca' failed

Failed to clone 'modules/ca'. Retry scheduled

If you want something that you’re going to commit local changes to though, I would recommend that you instead download the tar file for the 7.0.1.1 release and initialize a new git repository from those files to hold your changes all together. That’s a lot easier than handling the multiple repository links that you’d have to manage if you start from our tagged repo’s.

 We use the "tag release" as the point release and handle all official

patch files and local changes within others path, because I don't want

to keep the main release repositories from EPICS community inside local

repositories. Our repository actuall ykeep epics-base within our base as

"a module". For example, our base repo is e3-base has epics-base as its

submodule. We keep all other modules same as that structure.

 This approach gives me more extra time to do more technical works not

to sync and to maintain repositories among all different repositories.

Technically, I don't need to track down all changes between my

interesting release versions. Git allows us to do so. We download latest

commit, and checkout where we would like to go, and apply all necessary

patches into modules.

 BTW, from my view, it is not OK to change anything which we release

past in repository history. It should be as it was. However, I know

sometime it will cost a lot. Thus, you can ignore this view, because of

my lack of contribution to the community. I am going to explain here to

use https instead ssh.

  Thanks,
  Han

HTH,

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System