[jira] Closed: (GERONIMO-2633) SVK synchronization patch for 12-06-2006
[ https://issues.apache.org/jira/browse/GERONIMO-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMO-2633. --- Resolution: Fixed SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: https://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0-M5 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties: -- $Rev added Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- xalan, xerces artifactItems added -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2844) SVK synchronization patch for 02-16-2007
[ https://issues.apache.org/jira/browse/GERONIMO-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMO-2844. --- Resolution: Fixed SVK synchronization patch for 02-16-2007 Key: GERONIMO-2844 URL: https://issues.apache.org/jira/browse/GERONIMO-2844 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 2.0-M5 Reporter: Tim McConnell Assigned To: Tim McConnell Fix For: 2.0-M5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2844) SVK synchronization patch for 02-16-2007
SVK synchronization patch for 02-16-2007 Key: GERONIMO-2844 URL: https://issues.apache.org/jira/browse/GERONIMO-2844 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SVK
Hi Vamsavardhana, No they're certainly not causing any problems--I was just curious about them more than anything. I've been ignoring most of the smerge conflicts due to their omissions, but sounds like they should be kept in sync so I'll take care of them if they're missing. Also, to address your second question, it will make it easier for me if you commit related 1.2 and trunk changes simultaneously, but don't no one should feel obligated. That said though--I wouldn't try to dissuade you from doing so. Thanks much Tim Vamsavardhana Reddy wrote: Tim, I have been adding $Rev$ $Date$ to any of the files that are getting modified and that don't already have these tags. Is this causing any trouble? One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? --vamsi On 12/6/06, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
I'm not sure what you mean... you are seeing diffs or conflicts? Normally svk will handle trivial diffs like this... so while it will show up as a difference, there is no conflict, smerge should be able to resolve this with no user interaction. Or do you mean something else? --jason On Dec 5, 2006, at 6:26 PM, Tim McConnell wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with - C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use -- baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
On Dec 5, 2006, at 8:34 PM, Vamsavardhana Reddy wrote: One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? From an svk perspective it does not matter. --jason
[jira] Created: (GERONIMO-2633) SVK synchronization patch for 12-06-2006
SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Attachment: GERONIMO-2633.patch SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Description: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.xml SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Description: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties: -- $Rev added Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- xalan, xerces artifactItems added was: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.xml SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties: -- $Rev added Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- xalan, xerces artifactItems added -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SVK
Good info--Thanks Jason Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
Tim, I have been adding $Rev$ $Date$ to any of the files that are getting modified and that don't already have these tags. Is this causing any trouble? One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? --vamsi On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use -- baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
svk
Found some good info tutorials on svk...http://www.bieberlabs.com/wordpress/svk-tutorials/ -sachin
