What about Git support?

Are you missing a feature? Request it's implementation here.
sorin_carbunaru
Site Admin
Posts: 253
Joined: Mon May 09, 2016 9:37 am

Re: What about Git support?

Post by sorin_carbunaru » Wed Oct 02, 2019 3:29 pm

I'm glad to hear your colleagues love the Git integration :D ! It feels good when the clients are happy with your work.

chrispitude
Posts: 65
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Fri Nov 01, 2019 4:48 pm

I just installed the latest v2.0.0 update of the Git plugin. There is support for rebase-pulling - I'm excited to try it out!!

A quick question to everyone... We have our *.xpr Oxygen project file stored in our Git repository, so that (1) pulling the Git repository down creates a ready-to-use project, and (2) we can share project-wide settings like hotkeys and transformations.

However, we're finding that some day-to-day actions cause a user's *.xpr file to get modified. For example, let's say I change the map context in the DITA Maps Manager:
git_xpr1.PNG
git_xpr1.PNG (21.23 KiB) Viewed 59 times
This causes the project file to show up as a changed file:
git_xpr2.PNG
git_xpr2.PNG (16.64 KiB) Viewed 59 times
And when I look at the differences, the only change is the map context setting:
git_xpr3.PNG
git_xpr3.PNG (37.87 KiB) Viewed 59 times
How are others handling modifications to shared *.xpr project files in a Git flow?

Radu
Posts: 6541
Joined: Fri Jul 09, 2004 5:18 pm

Re: What about Git support?

Post by Radu » Mon Nov 04, 2019 11:50 am

Hi Chris,

Indeed Oxygen auto-saves various settings at project level. Besides the root map setting another setting we auto save at project level is the association between an opened map and a publishing scenario and we have users having problems also with this.
Honestly I'm not sure how to best handle this on our side. I mean, saving the root map setting at project level is useful, if you give the XPR to somebody new they just need to open the XPR and they will have the root map properly set.
At some point we wanted to add a special setting for the XPR project, something like "[ ] Lock project settings". This setting would be checked by you (the admin) before committing the XPR on GitHub. And for anybody opening the XPR, Oxygen would no longer save settings at XPR level. But what would happen if they change the root map? Would the setting get auto saved to Oxygen's global options?
Or if you are never interested in imposing the root map, maybe we could have particular settings like "[ ]Save Root map settings at project level" or "[ ]Save scenario associations at project level". And you could uncheck both these checkboxes (which would add some flags inside the XPR), then share the XPR with others...

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

chrispitude
Posts: 65
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Tue Nov 05, 2019 5:48 pm

Hi Radu,

For smaller projects, it's definitely useful to store the root map and scenario associations in the project file. Like you say, any user can obtain and open the project, and they will have sensible default behaviors ready for them.

I believe this becomes less ideal when there are multiple users or multiple root maps (or both).

Let me think out loud here...

Multiple root maps

When I work with multiple root maps simultaneously, for me the concept of a global root map setting becomes more hindering than helpful. It would be nice if each editing window remembered the context in which it was opened. There are various places where the filename is shown (main window bar, bottom status bar, tooltip for editor tab) and these could display the root context in a suffix for clarity.

For example, let's say I have a shared topic S in books A and B. If I open S from A's map and S from B's map, each of these editing windows should remember its root context and resolve references accordingly. If I copy a figure from the S-from-A or S-from-B window then paste-special as a keyref link into another topic editing window T, the reference should be constructed using the keydef/scope information from either bookmap A or bookmap B, respectively.

Would this editing window root-context completely subsume the need for the simpler global root context? I am not sure, because I don't know what non-editing features the global root map setting affects.

Multiple scenario associations

The situation is less clear to me when there are multiple users and multiple writers. Perhaps it would be useful for two levels of association:
  • The project administrator sets up all associations that might be useful when working in the project, and
  • The users can select their own associations within the set configured by the administrator.
This would work in conjunction with my other filed feature request, for the "Apply Transformation Scenario(s)" button to be a drop-down that lets you run a single transformation from the associated set, thus preventing the need to change the associated net.

----

For both the root maps and scenario associations, I am just thinking out loud. These ideas are more complicated than having an option to lock the project file and push any varying settings to the user's global file. They might have usability or technical issues I haven't considered.

I hope other users can share their thinking too!

chrispitude
Posts: 65
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Tue Nov 12, 2019 4:12 pm

The situation with our shared project file became unworkable. Despite telling everyone not to include it in commits, it still accidentally got staged/committed/conflicted.

For now, we have a MASTER project file in the repo, then each writer copies it to their own working copy. I added the following lines to our .gitignore, which ignores any project file except our master file:

Code: Select all

*.xpr
!our_books_MASTER.xpr
This means that writers don't get updates to the project file automatically, but we can work with that for now.

Post Reply