New post
Question
· Apr 13, 2018

Git behavior

#Caché #Git

We are going to start using Git within Cache.

One question came up - if the branch that you checked out does not have the class or mac file, what is the correct thing to do?

Should we delete from Cache or should we just keep it?

I'm leaning more towards deleting it because Cache should reflect what is in your work folder in git. But other team members are saying to keep it.

Discussion (16)1
Log in or sign up to continue
Eduard Lebedyuk · Apr 13, 2018

You should delete it.

Let's say you have ClassA and ClassB. And ClassA calls methods of ClassB. Then you delete ClassB from the repository, but it stays locally. And everything is fine for you and works, but down the line you start a new installation and suddenly it does not work, because ClassB does not exist.

When you're working with Git, or any version control system for that matter, you can easily rollback to any state of the repository. So once you commited something you can always get it back.

On some of our projects we first mark stuff we want to delete as DEPRECATED. But it stays in the codebase and in the repository. After a while, after we're reasonably sure that we in fact do not need this, the actual delete from the repository and from the server happens.

0 0
Roberto Cahanap · Apr 13, 2018

How would you mark it as DEPRECATED?

Do you set up a property or parameter within the class to mark this?

Also, how would you handle MAC files?

So the process would be:

1. Checkout the branch

2. Import the files into Cache (cls/mac)

3. Go through all of the files in Cache and check if it's in the physical OS folder, if not mark it DEPRECATED.

Thank you for your help!

0 0
Eduard Lebedyuk · Apr 13, 2018

How would you mark it as DEPRECATED?

As a comment on a first line.

Also, how would you handle MAC files?

The same.

3. Go through all of the files in Cache and check if it's in the physical OS folder, if not mark it DEPRECATED.

Well, if you decided to deprecate several classes then yes.

Check out this series of articles on Git and Continuous delivery:

First article covers git, branches and how it can all work together in development.

With Continuous Delivery you can easily automate the tasks of syncing your branches and environments.

1 0
Evgeny Shvarov · Apr 13, 2018

Eduard, do you think it makes sense to DELETE everything in a namespace and then import code from checkout?

Consider DeveloperA deleted ClassB from repo and from his local NamespaceA

DeveloperB checkout repo and with only classA but still has ClassB in his local NamespaceB. What will delete ClassB in DeveloperB's working system?

The only "automatic" solution I see here is to check out and import classes into clear or new Namespace.

Or never delete classes, only "deprecate" it

0 0
Eduard Lebedyuk · Apr 13, 2018

The only "automatic" solution I see here is to check out and import classes into clear or new Namespace.

  1. Build git diff.
  2. Import new/modified classes.
  3. Delete deleted classes.

Cache Tortoise Git automatically deletes classes deleted from repository.

Or never delete classes, only "deprecate" it

Depends on how much dead code you have. If say a few classes then it's fine. But large amounts of dead code just make codebase even harder to read.

1 0
Eduard Lebedyuk · Apr 14, 2018

There are two operations:

  • comparing repository/instance
  • bringing one on compliance with other

The first part (comparison) could be easily generalized, as the underlying Git repository allows us to do it  regardless.

The second part, however is very specific and should be implemented as a part of the source control hooks. I don't see how it could be generalized.

In my GitLab code I specify an interface which end user should implement - it's a method that accepts a list of deleted items (filepaths). Implementations of this interface should first translate file paths into internal names (i.e. /src/Utils/Math.cls -> Utils.Math)  and then delete them.

That said, full build from scratch can solve the issue completely. That's a decent approach to take towards more "lively" environments.

Finally, as we're talking about deleting classes, at least for me it's an extremely rare case. Do you encounter it often? How & Why?

0 0
Roberto Cahanap · Apr 19, 2018

Edward, I've been talking about the solution that you proposed to my team members about marking the class or mac as DEPRECATED.

We are looking now in the documentation on how to programmatically  do this. I think we found the Cache class to open a class and mark it as DEPRECATED.

We can't find a way to open  mac file and mark it with a comment like you mentioned.

Would you know how to programmatically do this or should we call WRC?

Thank you for your help.

0 0
Mike Wragg · Apr 19, 2018

Neither - I think it best to just remove all the code and leave a stub with just a comment (usually with the change request id and reason).

That ensures the unused code is removed from all downstream libraries, so does not pop up in searches and testing, and yet keeps a record of its previous existence. I've always been against leaving unused code in source files, even if it's "commented out".

0 0
Roberto Cahanap · Apr 20, 2018

The argument/discussion now with our team is that if developers have local files (macs) that they personally use only for themselves then we don't want those deleted. 

We are thinking of having a convention where if we have these macs that begin with "z" (zTest.mac, zDataFeedABC.mac, etc) then we will leave those alone both in git and in Cache.

0 0
Mike Wragg · Apr 20, 2018

Yes, we have something like that, except we use the letter "q" as the prefix, and we follow it by the programmer's initials so that it becomes a "personal" set that is left alone in all namespaces, dev-test and live. We also extend this to rule to globals and things inside the application like functions, screens, tasks, etc. The in-house configuration management system we use ignores them so they are left untouched. It's a useful convention.

(We might have used "z" like you, but it was already taken for "utility/library" stuff.)

0 0
John Murray · Apr 20, 2018

If you're not already committed(smiley) to using Git, you might consider the Deltanji source code management tool from my employer, George James Software. One of its features is the ability to manage deletion of code components (e.g. classes, routines, files, lookup tables, HL7 schemas etc) and propagate those deletion downstream in whatever workflow  you have configured (e.g. DEV, QA, STAGING, LIVE).

0 0