Experimental Physics and
Industrial Control System

"Johnson, Andrew N. via Core-talk" <[email protected]> · Wed, 30 Jan 2019 23:08:08 +0000

On Jan 30, 2019, at 4:40 PM, Jeong Han Lee <[email protected]> wrote:
> 
>>> 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.

Ah, okay that makes sense.

>  I am waiting for patch files or 7.0.3 release.

There will probably be a 7.0.3 release within a few weeks, there are a few bugs and a regression that we want to fix.

>> 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

Please try the two commands I showed above, which do *not* use the —-recursive flag  to git clone, and checks out the submodules as a separate step. If that doesn’t work either, what version of git are you running?

I don’t think there will be any difference using ssh or https BTW. I actually did the above using a local repository with the latest 7.0 branch instead of the URL I included, but I would be surprised if the transport matters.

>  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.

It sounds like we have a similar philosophy, your general approach sounds close to mine.

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System