That process sounds like it takes care of the SVN copy of things....but how do you manage that same things on a migration to Production? An XML copy of an object that was renamed in Dev won't tell you what the old name was, or allow you to rename it automatically in Production.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Campbell, Paul (Paul) Sent: Friday, January 20, 2012 6:31 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion On a rename, I use the svn move command using the old object name and the object name, for a delete I use an svn delete --force. As for forgetting to turn a task on and off, I have the table field that shows the workflow that is marked with the task name, and I am about to add a button to remove the selected item from that task, this button will do an svn status to see what the modified state is using column 1 of the output, if the state is a ? or an A, then I do an svn delete to remove the file, if it is an M, I do an svn revert to put it back to original state. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, January 19, 2012 4:04 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion That's an interesting approach. We actually don't use the Object Modification log because too many developers modify too many things that they don't want put into the code....plus we can't trust them to remember to turn on and off tasks :).... The approach we took is that you store your workflow in a packing list, only when you are 'done' with your module of work do you notify the migration tool that you are ready for this code to go into the migration package. This approach allows for prototyping and such without anything accidentally getting put in. Out of curiosity, how do you handle workflow renames/deletes through your current process? -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Campbell, Paul (Paul) Sent: Thursday, January 19, 2012 1:40 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion Yes, That's correct -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, January 19, 2012 3:23 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion So...when I look up that form I see "Reserved for future development."...which tells me that you are hijacking that form...which I'm cool with...but just to understand what you are doing here.... So...you create a 'Task' record....so anything they do while they have an active task gets associated with that task's data, right? So you are using the Task form as your method to identify the 'work' that's necessary for any given story....then via custom workflow you utilize processes to export the object and store it in svn...then use SVN to generate your total list of code for a release... Do I have that right? -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Campbell, Paul (Paul) Sent: Thursday, January 19, 2012 11:31 AM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion I am actually just finishing up an integration with subversion and I to store all of the work done on a specific group of work (we are using KANBAN development methodology so a group of work is a story to us) we create a branch in SVN for each story, and store any changes that are a part of that story to a checked out branch on the servers filesystem. I started out using labels that were created in Dev Studio, but I moved away from that, due to the fact that if you modify something after the label, you lose the association to the label (from what I see). What we have done is use the AR System Version Control: Task form and tied the object modification log to an active task. Here is how our process works 1. Create a Task record for your story. When this happens, a script on the server calls the svn branch command to make a new branch, and checks it out to the server filesystem. 2. Once the branch is formed and checked out, set the task to active (I modified the status values on task) 3. Start your work, every time you modify workflow, an object modification log entry gets made, when that gets made, a lookup is done to the task form where owner on task=submitter on mod log and status on task=active, save the task name and use that to determine what branch working copy on the server to write the file to. 4. When the Task name is retrieved, I write a def to the branch directory on the filesystem (We use XML for def file format instead of def since we manually modify the defs to change web service call urls and passwords. I wrote a java app to export the workflow, you could do an perform-action-save-attachment to do the same for a .def formatted file). I don't check in the code at this point. 5. Once your work is done, I have a make package button that finds all the changed files on the filesystem using svn status command on the branch directory, tar up the individual files that I can loop through and call the importdefinitions java app code described in the manuals to move code to my testing server. I also attach the tar file to the task so a developer can save it to their client from the task form. 6. Once all the testing is done, you make a final package, then you commit the branch and merge it back to the trunk with all the comments you need to add Note: if a developer gets pulled off a story to do something else, they have to change the status of the Task record to paused status before making changes so it doesn't get associated with the Task they were working on. I also have a table on the task form that shows object modification log entries with the task name and LatestVersion=yes so they can see what is associated. I have some real "Tropical Fish" like developers that roll belly up when their environment changes, and even they aren't balking so far. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, January 19, 2012 12:45 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 7.5 Integration with SubVersion Rajesh, Agreed with the comment about lack of FORCED comments, but not the lack of comments. If you right click on an object, you can add a Version Control Label, and if I'm not mistaken, when that object is saved to the log, that Label and the Comments of the label go with it. I would not agree with the 'lack of control'. As you know, just because someone modifies code, doesn't mean you want to include the changes into your production system. This is where your integration would move the items into the external system you want...and along with the above labels and comments you can decide if you want to include it or not, in the same manner you would with previous versions integrations. Regarding the 'very slow'...I would be curious to know what sort of metrics you have on this....because of the fact that it's just a form and such you should be able to turn on logging and see where the time is spent. I have this turned on in Dev and Prod with no noticeable slow down. Any delay that I can conceive of would be related to exporting the object to def and storing it in the log...this time obviously depends on the size of the object. The servers I have right now have about a dozen developers working on them every day. Regarding 'less load'....if you add a process that must take place on every save (which is what the modification log does) then you aren't dealing with less load, you are adding to the load...in the case of the modification log, the load is added to the server (which should be able to scale well)...as opposed to the previous integrations which were client based and thus less scalable. If you wanted to write your integration with Eclipse Plugins, you can certainly do that as well...I imagine you could write a plugin that fires on save and kicks off a dialog collecting the information you want and putting it into source control from there...but I would think that would be 'more load'...not less 7.5 also has object reservation...which is similar to 'check out'....so you could have the integration (plugin) fire on the removal of the reservation.... All of these are options that you can explore as you wish...most functions have a price, in this case, there WILL be an added load somewhere, server or client, but there will be a load associated. -----Original Message----- From: Rajesh Shinde [mailto:rajesh.shinde...@gmail.com] Sent: Thursday, January 19, 2012 10:07 AM To: arslist@ARSLIST.ORG; LJ LongWing Cc: Rajesh Shinde Subject: Re: Remedy 7.5 Integration with SubVersion Hello LJ, Thanks for the quick response. The Problem with the 'Object Modification Log' is that : 1. It saves the def file, without prompting for any user comments. 2. We do not have any control over the changes which we want to commit and the ones which we want to ignore. Please correct me if i am wrong. Also We have observer that the server becomes very slow if we have enabled the Object Modification Log functionality as their are multiple people working on the server simultaneously. I need to have a source control which can be integrated with Remedy 7.5, hence giving user the choice of committing the changes with proper comments and also less load on the server. Regards, Rajesh kumar Shinde ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
