abapGit
abapGit copied to clipboard
abapGit
Transport to zip - incorrect object versions
Hi, I'm phrasing this as a bug, but it could also be a question.
When I select a very old transport to be exported into zip, the current versions of the objects in that transport are exported. I expect the versions of the objects at the time of transport release to be exported.
Context (of what I'm trying to achieve): https://community.sap.com/t5/technology-q-a/keep-old-abap-versions-ie-in-git/qaq-p/13638327
abapGit serializes the active version,
https://docs.abapgit.org/development-guide/serializers/overview.html#overview
Only the active, most recent, and consistent version of an object shall be serialized.
I did start https://github.com/abapGit/git-historical-extract some years ago, but its a lot of work
In my understanding this would not be feasible to do in abapGit. The transport doesn't store the actual object in the DB, but retrieves and writes it to the file at the time of release. As we cannot rely on TR files being present, let alone decode them, the only way to retrieve the version at the time of transport would be to reconstruct each object from the version history. As Lars puts it, a lot of work. As not all objects have version histories, this becomes an impossible task to reconstruct a complete system snapshot. The best idea I can offer is similar to what was discussed in the thread, get a fresh SAP system, apply each TR and push. But then you also have version issues, so would have to start with the first version and upgrade along the way.
Agreed Mike, Lars, indeed a lot of work. With abapGit I would go the version db route, that is, determine the exact version at time of transport release, and serialize that. (@pokrakam , for my understanding which objects don't create or have versions when transport is released?) Not sure where to start, but all vrsx* tables (https://me.sap.com/notes/130906/E) seem likely candidates.
With gCTS I would go the transport file route (co, data files), because of the interesting gCTS capability of versioning customizing (transport) data. This would definitely require the data files; the alternative Table Change Logging (table DBTABLOG) might also be used if that had always been ON in the system. I've been playing with r3trans -l
Replaying transport files into a clean system might also run into all kinds of trouble, because of many upgrades, dependencies evolving throughout the years (ie conversion from ECC to S/4, or even older R/3 versions). Not sure if the (inactive) objects of failed imports can still be serialized in abapGit. Given @larshp 's quote on serializing active version, I would deduce: not possible.
[edit all vrsx tables] [edit added last sentence on inactive objects]
Anything customising or table-based objects may or may not have versioning or change logging. Workflow templates have versions, workflow tasks do not. Most customising won't have versions, but may have table logging. BRFplus has versioning and transportability configurable at application level. In other words, each non-code object type has its own rules.
An issue, as you probably already understand, is that you're trying to reconcile opposing systems. SAP broadly follows the classic version control system (VCS) model, where each file or object has its own version history. Locking an object in a transport is the equivalent of a classic check out (lock) and check in (release). Git is a snapshot VCS model, whereby the state of the entire repo at the point in time is preserved in a commit. So the way to get around it is to replay all the activities and commit at each step. Easily done with AG or gCTS in real time when it happens, much harder to do historically.
I think it may be easier to tackle the problem from the other end. I don't know what the purpose is, but I assume at some point someone will want to view or query the history. Might it not be easier to reconstruct this at the time it's needed for the objects that are requested?
@pokrakam , my requirement was to keep a history of all changes / versions easily accessible (hence Git for example) without a running ABAP application server (better: S/4 instance). Probably I go for an r3trans wrapper (having all co, data files), or still keep an S/4 instance around (container?, with only workbench/customizing without business data).
It's an interesting topic but out-of-scope for abapGit. I suggest taking the discussion to our slack where a similar thread has come up: https://abapgit.slack.com/archives/C4K5GM9D0/p1715689865045719
@mbtools , not sure what the slack discussion is about, as I can't access it. Totally understand the wontfix label. This issue is on my side projects list, although I have more urgent side projects. :)
You can join the abapGit slack channel here: https://communityinviter.com/apps/abapgit/abap
Fine with me. I'm not getting to this in the coming months...
Met vriendelijke groet, kind regards,
Wout de Jong
On Tue, 16 Jul 2024 at 20:30, Marc Bernard @.***> wrote:
Close?
— Reply to this email directly, view it on GitHub https://github.com/abapGit/abapGit/issues/6884#issuecomment-2231551289, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWK6O22X3OFOG6T5KBBF5TZMVRFBAVCNFSM6AAAAABFPMPS6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGU2TCMRYHE . You are receiving this because you were assigned.Message ID: @.***>