Dfyjkt

With this question, I just want to get some comments and advices on both processes.

I purposely mentioned eGIT pluggin because I can eccept that GIT is a popular VCS which updates the code to git server and all rest things like stashing, branching etc, But in Xpages we need to create an ON-Disk project and it needs the source control with the local ntf so that we can sync the changes from git ondisk project to local ntf and vise versa in which eGIT pluggin helps us to set it UP.

For more expalination, we have 2 different locations(Both time zones are different),Example Location A and Location B.On Location A it seems that every things works fine but on location B when the changes are pulled on on-disk project some of our developers found some issue with syncing with ondisk project and didnt get the changes from ondisk project (Sometimes it might be because of generated meta data), where we have found the possible reasons for that. So we have decided
to

1. create a replication from one master template "xyz" from location B to
   location "A" on all developers local, Template "xyz" and replicate when
   changes are done.


2. stop pulling the changes from the git


3. decided to only push changes and replicate changes to master Template "xyz"
   on Location "A".

Now the question how correct is the replication process work when multiple developers works and replicate there changes , how secured will the code from all the developers who are working on Location "A".

what are problems that any xpages developer faced when using the egit plugging to sync changes on local template.

How replication will work here on top of git process using eGit,
what are the possible problems can be expected with replication process while working as team.

last few weeks we found out that after replicating the template from Location "A" to Location "B", some of the custom controlls get duplicated with different signer but with same name, Now nobody can predict that what went wrong here.

Been using Git with XPages now for years, also in projects with multiple developers. Sometimes it's a pain, but most times it works pretty well. And it's a whole lot better than not using source control at all, especially in multi-developer teams. You simply can't live without it IMHO.

There's not really a concrete question in the text above, but I can share some of my experiences:

• I don't use eGit, but an external Git client (SourceTree). That's not because I don't like eGit, but because I don't like the extra dependency it adds to Designer. I like to keep Designer as close to a standard install as possible.


• Use Swiper in Designer. Git with NSF files is a much bigger pain without it.


• Commit only what you actually changed in the NSF. The on-disk project sometimes makes you think you also changed the database properties or icon (that's a big struggle), but just ignore those changes. If you forgot what files you changed, you need to commit more often (commit locally first, squash your commits and send them to the server).


• The Git repo is the single and only source of truth. When developing, forget about templates. Just sync with the ODP. In my experience, the ODP change detection and sync has gotten better with the new Eclipse version in Designer.


• If you create a Git repo for an ODP, store the files from the NSF always in a subfolder (or multiple if your application consists of multiple databases).


• If you merge commits from someone else, merge in your Git client, solve any merge conflicts and only then you sync with the NSF.


• Turn of auto import/ export in your Designer > Source Control preferences. Makes Designer more responsive and gives you control over the process. You just shouldn't forget to do it.

Source control for NSF project is as poor as it can get. The only thing you can do to mitigate the various problems is to give up on some basic assumptions that are the absolute norm in any other respected dev environment and roll out acrobatic-loop-like strategies.

I assume you have already:

1. disabled binary DXL option (DDE Source Control)


2. enabled both automatic import/export of the design elements (DDE Source Control)


3. enabled build automatically option (DDE Workspace)


4. enabled refresh using native hooks or polling option (DDE Workspace)


5. installed OpenNTF Swiper plugin and enabled it for the project

From there I would arrange the work to have a sort of top-down configuration respecting the template. That means:

• each dev has his own local template instance (and therefore different template id) created from and synced with the git enabled on-disk project


• each dev works with his own local server (and therefore replica of his personal local template) for dev/testing purposes


• each dev commits/pushes/pulls any changes to/from the git remote repository


• an authorized dev and/or common DDE client - only one! - creates from and syncs with the git enabled on-disk project onto another ntf file stored on either server A or B - and then Domino replicates to A or B. That ntf effectively becomes the only authorized production template existing for the org

In this way you have clear separation between dev local templates and production server template. The replica id for each one of them is different and therefore they can never replicate between each other, not even by mistake. In this way you truly ensure that only what is git controlled be the source of truth and avoid funny replication/save conflicts typical of domino envs with multiple devs working on the same template.