You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Tim McConnell <ti...@gmail.com> on 2006/12/05 01:03:13 UTC
SVK
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
Posted by Jason Dillon <ja...@planet57.com>.
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
Re: SVK
Posted by Tim McConnell <ti...@gmail.com>.
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* <tim.mcconne@gmail.com
> <ma...@gmail.com>> 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
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <ti...@gmail.com> 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
Posted by Tim McConnell <ti...@gmail.com>.
Got it--thanks much
Tim
Jason Dillon wrote:
> 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
Posted by Jason Dillon <ja...@planet57.com>.
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
Posted by Tim McConnell <ti...@gmail.com>.
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
Posted by Tim McConnell <ti...@gmail.com>.
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
Posted by Jason Dillon <ja...@planet57.com>.
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