VCS Integration

[GISTech]

Would be useful to be able to track versions of my Pro projects over time.  Ideally, via git locally, or even with a repository such as github, gitlab, etc.

An idealized workflow would check in my .aprx to git and I'd commit changes as the project evolves via an integrated interface (much like IDEs use to make version control painless).  This would permit me to version projects (rather than saving ProjectName_old, ProjectName_older, ProjectName_whatever in the filesystem) in a proper versioning system, with all the facility that provides. Could be implemented for maps, layouts, model-builder workflows, jupyter notebooks, or the whole project.

--gt

[curtvprice]

Git and other source control systems are designed to modify changes in text files (code). Binary data can't be easily tracked with changes only line by line so technically this isn't really possible.

[GISTech]

I agree that it is a technical challenge.  And possibly not worth the effort, given that likely a low fraction of users might want it. 

However... I don't think I'd go so far as to say that it isn't technically possible.  Certainly, there's room for me to be misguided here... but here's my thinking on why I believe 'binary == impossible' is not the right way to think about a Pro project:

My understanding is that git relies on a suitable 'diff' utility being implemented which can isolate and flag atomic units of changes from one rev to the next. In a text file, that's typically a single line of text. The text tools for this are old, stable, widely available (diff, merge, etc). But it doesn't have to be text, and atomic changes don't have to be entire lines. Jupyter notebooks, to pick one example, may include nodes containing rich mime types other than text, yet may be handled by git.  This hinges on a specific diff and merge utility rather than the standard old-school text diff/merge. The nbdime utility seems to be the tool that Jupyter Lab uses to integrate git with its interface to handle these cases.  

If Pro were to include some sort of VCS integration, such an aprx-specific diff/merge facility would be required.  It would likely be proprietary, tied tightly to the aprx format, and would certainly up the complexity and footprint of this feature's addition. 

But probably not as much as one might initially think.... The aprx format is nothing more than a PK-ZIP archive containing a main XML (i.e. text) file and a folder structure holding more XML files (also text) and a few odds and ends (binary) depending on the project. So even without invoking an Esri API, one might use standard XML manipulation tools to find and isolate individual text lines of difference once the unzipped folder structure is exposed.   In theory.

That's the long way to say that yes it's harder than a flat text file. But it is far from unachievable with existing text-based tools.

--gt

[curtvprice]

Good points!