2

We're in the process of migrating into GIT from CleaCase UCM 8.0.1.3. We have several projects that use dynamic views. and I would like to know, if there are some best known methods and use cases of migrating the use of dynamic views in GIT.

The simplest projects, just using one dynamic view and all the team writes to the same place. It holds only documentation and they need the ability to know immediately who is touching which file. It is only one stream for all. Converting that into GIT is simple. Just create a repository in a global network path. Any other ideas ?

The complex ones, are as follows. Lets say I have two components: Global, Specific. The "Specific" one is an ordinary snapshot view for each developer. The "Global" one resides in a dynamic view and any change into it makes the Specific one to use the change done in the Global, immediately.

Adding to that is the permission issue, only specific people are allowed to make changes in the Global component.

And more, There is an automatic mechanism that runs in specific machine that makes a change automatically to the Global component by import from some other 3rd party application.

And last, there is also authorization mechanism for each folder in the snapshot part for specific people in specific folder. That's another issue, I added it as background information.

So, the question is, any ideas how to manage it in the most easiest way ? push/pull hooks are a solution we're investigating now. is there more nicer solution ?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Elyahu
  • 226
  • 1
  • 2
  • 15

1 Answers1

1

Just create a repository in a global network path

That seems the most straight-forward way to benefit from the shared access provided by ClearCase dynamic views.

Adding to that is the permission issue, only specific people are allowed to make changes in the Global component.

That should be managed by an ACL (Access Control Layer) like gitolite.

The "Global" one resides in a dynamic view and any change into it makes the Specific one to use the change done in the Global, immediately.

That sounds like:

  • Global should be declared as a submodule of Specific
  • the submodule should be configured to follow a branch

That way, any git submodule update --remote would update Global is any new commits were pushed.

If your repo hosting service provides webhooks (like gitHub does), then each client can have a listener for a push event, and trigger the submodule update.
Even if a private hosting service doesn't have webhooks, you can implement one with a post-receive hook (generating the JSON payload to be send to registered listener clients).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250