Source Control of altered objects

Welcome to the POB User Group Online Community! Forums PUG International Source Control of altered objects

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #3461

    Hello All

    We are developing things and there for making changes to the custom XAML. You can assign the changed items to change sets, but can’t revert unfortunatly. Because of this, we want some sort of version control. Exporting the item isn’t really the best way (though possible) for it will contain more then just the change made.

    How do you keep track of changes made (versioning) so you can revert to any point in time?

    In the custom xaml you change only the position nothing else and therefor the custom XAML with the old situation is version 1, and the new is version 2

    Thanks for the information.

    Stefan Reichelt


    that’s an interesting topic. We don’t really have a solution running for it, we just work with a three-step development (DEV->TST->PRD) where we have the chance to make really sure that only working changes come into PRD.

    What I always do: I use the Notes memo of my RFC cases to keep what I changed. And of course it is possible to keep both versions (before and after) in that memo, so you can always go back to the point before change X.

    Just an idea: The XAML source is of course saved in the database (Pob_Xaml_Block), and you could automatically write changes into another DB, e.g. with a DB trigger. The trigger could not only save both versions but also the current timestamp and the internal version number into the target table. In many external tools (even Notepad++), you can easily highlight differences between both versions. Or you import the changes back into a Custom Table again. There you could create a J type field pointing to the Window table, so you can see the whole history of any window directly in POB and even group it by that field.



Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.