1. Arcady Abramov
  2. PowerBuilder
  3. Sunday, 6 October 2019 12:24 PM UTC

Hello, all

We are trying to move to Azure DevOps Git source control and we have a theoretical question. Is it possible to lock access to a checked out file for all users, except for the one who did the check out?

 

If not, then how well does conflict resolution work in PB, especially on DWs?

 

Thank you

Arcady Abramov

 

Olan Knight Accepted Answer Pending Moderation
  1. Monday, 7 October 2019 22:30 PM UTC
  2. PowerBuilder
  3. # 1

Just....don't.
Don't use GIT.
Use WizSource. Keep it simple, clean, easily integrated with PowerBuilder, and inexpensive.

Olan

Comment
  1. Armeen Mazda @Appeon
  2. Tuesday, 8 October 2019 00:03 AM UTC
Hi Olan, Arcady mentioned he wants to do Azure DevOps. Microsoft's DevOps is all centered around Git. I know you are a big fan of WizSource and I'm not saying it's a bad source control solution, but please be carefully about blindly recommending stuff.
  1. Helpful
  1. David Peace (Powersoft)
  2. Wednesday, 9 October 2019 14:28 PM UTC
Hi Armeen

From what I have seen GIT is a poor solution for PB, the issue being merging changes in DW source. The fact that GIT does not support checkout locking is a problem for me as I can see a loss in productivity sorting out conflicts further down the development line.

Having said that I believe that these issues can be resolved with proper development management. Let's face it we do not have huge development teams working on a single PB app, it's far to productive to require that! So with proper management and allocation of work there should not be conflicts with DW source.

As always people look for an IT solution when quite often the problem can be resolved with planning, communication and organisation.

We have never had a problem either way....

Cheers

David

  1. Helpful
  1. Armeen Mazda @Appeon
  2. Wednesday, 9 October 2019 17:08 PM UTC
If using an implementation of Git that supports file locking, which there are quite a few options, I don't see that Git is such a poor solution for PB. On the other hand, if a company has or wants to implement an organizational-level DevOps using Azure and Microsoft's stack, then PB not playing into this mix is going to be the real problem. So the point is with a combination of tools and processes, if a customer wants to implement Azure DevOps we need to be helping them solve that rather than making blanket statements about Git.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Monday, 7 October 2019 18:44 PM UTC
  2. PowerBuilder
  3. # 2

I agree with Miguel it is best to change practices to try to avoid.  Of course, sometimes it will happen and the tools for Git are usually good at resolving conflict resolutions. 

Bruce has done quite a few presentations on this topic, and if you haven't watched them I recommend at least watching his Git Bootcamp and carefully following his suggestions: https://www.appeon.com/developers/library/videos/git-bootcamp.html

Also, as Bruce mentioned in this presentation that there is versions of Git that do allow you to lock if you really want to work in this way.  For example, the on-premise GitLab Premium and Ultimate editions support file locking: https://about.gitlab.com/pricing/#self-managed

Comment
  1. Miguel Leeuwe
  2. Tuesday, 8 October 2019 06:05 AM UTC
We're looking forward to it !
  1. Helpful
  1. Miguel Leeuwe
  2. Tuesday, 8 October 2019 06:08 AM UTC
The problem with the free open source git is that it's not "private" as far as I checked the last time. GitLab does allow private repositories, but my wild guess is that they won't have a free "locking" version.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Tuesday, 8 October 2019 17:43 PM UTC
Free open source GitLab is on-premise, so definitely you can make it private. Perhaps you are talking about the free version that GitLab hosts for you?

I just checked and even the free version that GitLab hosts for you says it supports "Unlimited private and public projects": https://about.gitlab.com/pricing/

Anyway, here is a free open source file locking solution: https://github.com/git-lfs/git-lfs/wiki/File-Locking

And here is list of all the different free and paid Git implementations that support this: https://github.com/git-lfs/git-lfs/wiki/Implementations

  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Monday, 7 October 2019 02:26 AM UTC
  2. PowerBuilder
  3. # 3

This might be just a stupid idea, but I think that the best "conflict resolution" can be achieved by avoiding them in the first place, so here's my 2cts:

My approach (luckily I do have exclusive locks), if I'd have to work without locks:

1) Refuse! Tell my bosses to buy Gitlab Premium. Merge is something to avoid and takes up time and can introduce errors. Before buying, I do recommend to investigate how / if these locks would work with PB. There's (been) quite some bugs with "normal" Git already.

2) Depending on how many Developers might work simultaneously in a same project. I would write some kind of small program / webpage in which all objects are listed.

Before doing any modifications you would:

- Find the object and see if anyone is working on it.

- If free, mark it as in use by you (your name) and maybe some description

- When done with the object and checked in/synced with Git, erase your information from that little app so others can see it's free for editing.

Maybe that's a bit of a hassle but way less hassle than having to merge all the time and wonder which changes prevail over others. Depending on the amount of objects to merge, that process might take up a lot more time. You have to know why someone did a specific change, even when it was 2 months ago, .. .oh he's sick, oh she's on a holiday, oh no longer works here, etc. Or you make the implicated developers get together and do the merge together (if possible). 

Of course this would only work if everyone follow the rules strictly, even when doing small and fast changes.

 

Another way of reducing the need for merges, would be to divide different work to different people to reduce the possibility they'd clash in their need for objects to be modified. Have someone special for doing changes in common/ancestor objects and don't allow others, etc.

Division of work. I also think that's a bit what DevOps is about in a way, though I still don't see how that "thing" is anything else then Agile with a new suit, (and that's because I'm ignorant about DevOps).

Comment
  1. Miguel Leeuwe
  2. Monday, 7 October 2019 10:57 AM UTC
Another variant of what I stated before: Since datawindows seems the be the culprit when doing merges, you could also opt to "register" only datawindows as "virtually locked" by the use of some little application.



Git might do a good enough merge of the other objects.
  1. Helpful
  1. David Peace (Powersoft)
  2. Wednesday, 9 October 2019 14:31 PM UTC
All this seems like more work just to manage the source control system issues. Where is the RAD benefit in that!?
  1. Helpful
  1. Chris Pollach @Appeon
  2. Wednesday, 9 October 2019 14:58 PM UTC
Hi David ... Yes, the "KISS" principle is always the best productivity tool approach in my IMHO. I love check-out "locks" as it forces every developer who needs the same code to go and talk to the other developer who locked the source code to find out exactly what they are doing in same code area. Great team communication tool!

As a manager / team lead, I always checked the "lock" queue report in my SCM a few times a week. Then compared that to what I thought the developers were working on. Comparing the previous weekly locked object report as well to find out why the code was still checked out too. That gave me a good excuse to also to use my MBWA (Management By Walking Around) approach. I always used a "polite" approach ... Hi Judy / Bob, I see that some of your code is still checked out. Are there any difficulties that I can help you with. Quite often, that allowed me to help developers that were struggling with a certain enhancement. ;-)
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Sunday, 6 October 2019 15:41 PM UTC
  2. PowerBuilder
  3. # 4

NO! (ref: Stack Overflow)

You will need to lock the whole branch. Git's problem is that it is distributed. No concept of central repo to manage locks.

Very few git implementations add file locking. One of them is GitLab Premium.

HTH /Michael

 

Comment
  1. Miguel Leeuwe
  2. Monday, 7 October 2019 21:06 PM UTC
Thank you Chris that's veeeeery useful information, though I'll check out the link that Armeen gave saying Bruce did some presentation which shows a way of still being able to deal with the locks.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 7 October 2019 21:17 PM UTC
Yes, you will notice in Bruce's presentation that a) there is no Git LOCK menu item in the PB IDE and b) when he talks about Git Premium locking, that this is done via a central repository. The central Repo lock would be a "manual" lock as the PB IDE does not offer you any locking options currently. Therefore, locking would have to be done outside the PB IDE for the time being.
  1. Helpful
  1. Miguel Leeuwe
  2. Wednesday, 9 October 2019 15:10 PM UTC
I know some people who know how to hook into the pb-ide and add menu options which they have total control over. I'm to green with PBNI, but I guess that it should be fairly easy for someone like Roland S. to call some Git command line locking commands?

Maybe just an idea since everyone seems to go with the fashion of Git and Devops. Personally I hope I never have to use it. I want tools that make my work easier and more secure, not more troublesome and risky.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.