Commit less frequently?
Decodes PeopleCode bytecode and submits the code to SVN or Git
Status: Beta
Brought to you by:
erikh3
Menu
▾
▴
#8 Commit less frequently?
I'm sure you are sick of me by now, and for that I apologize. This is more of a question/enhancement request. Do you know if it is possible to only issue commits when a file is added? I noticed that because you are committing after you add each folder it adds tons of commits that I really don't care about. It also doesn't really seem to add any value because you wouldn't want to compare or have a history of folder additions just the peoplecode/SQL itself.
Here's the dilemma:
So I started off bringing in PeopleSoft Financials 9.1 into the svn since 01/01/2010. I chose that date because that will encompass all of the delivered customized code that has been altered. That created 145147 commits of which there were only about 20000 pieces of code/SQL. This made the respository huge and it made the dump file take forever to create. So I switched gears and decided to just run everything to file. I then did an svn import. So now I have one commit for my initial repository. I know that I lost all of the individual file commit log information but I will still have it going forward.
I really do appreciate all of your work on this project. I'm sure you have much better things to do then entertain my ideas.
Well, basically I'm doing
select ... from PSPCMPROG where <where-statement>
you've selected options that translated into a condition LASTUPDDTTM > '01-JAN-2010', but perhaps the parameter 'custom' would have served you better (--> LASTUPDOPRID <> 'PPLSOFT'). Obviously, this would not change the fact that every code segment or folder is committed separately, but it would probably have reduced the number of peoplecode/SQL segments significantly.
After your initial upload, have the tool run with the 'since-last-time' option, so that you catch newly customized code.
I can imagine that you also want to have the delivered version of that code: you can achieve that by configuring the tool to also track a second environment - have that second system commit to another SVN branch.
A typical use is that you choose your DEV to commit to the SVN trunk, and PROD to /branches/prod. Then, if you start customizing some PeopleCode, the delivered version of that code will be committed to the /branches/prod tree. This PeopleCode segment will only appear in the trunk after your first change, but the /branches/prod tree will also include the initial (delivered) version. So, there is less need to fill up the repository with delivered code just to make sure you have it.
Hope this helps.
Well one of the reasons why I wanted version control is because I want to see the changes that Oracle is making during patching which is why I wanted more to start with in my repository. I know you can get most of this information using compare reports but if you need to refer back to something after you have patched you have to dig up that old compare report or keep an old database instance to refer to which is extremely painful as I'm sure you are aware. With the repository I can refer back whenever I need to which is probably what I would be using this most for. I was just wondering if it was possible not to commit for every folder and if so would you consider it as a future enhancement.
Well, I see what you are doing but I don't think many people would be interested in tracking Oracle's changes that way. I really wrote this tool to deal with customizations and most implementations contain so few of those that size will not become an issue.
So, I don't think I'll work on this any time soon. I'll keep this item open - if other users think it merits attention, please chime in.