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
