On Wed, 2007-01-17 at 13:09 -0500, Andy Levy wrote:
> > > > >
> > > > > I am confused but I need to fix this to move on.
> > > >
> > > > Do a:
> > > > svn log -v svn+craigssh://app-serve@srv2.tobyhouse.com/home/app-serve/svn/th-db/branches/phase3/lib
> > > >
> > > > Find the revision where has been added (A) the file clwholename.rb for instance.
> > > >
> > > > Is it a revision between 52 and 138 ?
> > > ----
> > > yes, it is listed with everything else in revision 67...
> > >
> > > $ grep clwholename /tmp/svn-log.txt
> > > A /branches/phase3/lib/clwholename.rb
> > >
> > ----
> > I think I see a problem and am guessing that this is self-inflicted...
> >
> > the changes in trunk that resulted from the branch merge are all
> > numbered at 139 which clearly shouldn't be since they were all done
> > between revision 52 and 138
>
> I think you're misunderstanding how revision numbering works.
> Revisions numbers are global to the repository - each time you commit,
> you increment the revision number.
>
> So, if you took the changes in branch from 52-138, applied them to
> trunk, and committed trunk, the repository is at revision 139, which
> is what you're seeing.
>
> What merging does *not* do is take each individual change that you
> made in branch, and apply the change at each revision number to trunk
> at that same revision number. Trunk will always show that nothing
> happened between 52 and 138 if you didn't make any commits to trunk in
> that range - it will only show that a large change was committed at
> 139, which is the merge you did.
>
> > I am thinking that if possible, I need to revert the 'trunk' back to
> > revision 49 and then merge 52:138 again.
>
> Some define insanity as doing the same thing over and over again, and
> expecting different results.
>
> I think you probably used the correct command to merge, you just may
> not have understood what the result is meant to be.
----
You may be right on that. When I look at kdesvn, I can see which
revision # is associated with each file on the phase3 branch, but if I
understand you, these files just show up in my trunk as a result of
revision 139 - I guess that's what you are saying.
I can 'svn update -r 49' and my local directory is indeed back at that
revision but if I then say - svn commit --message="something" Nothing
happens, I presume because nothing has changed.
If I merge my branch into my local copy, I am probably good to go except
that as stated earlier in the thread, I won't have a 'clean copy' but
that is looking like the most expedient thing to do since a checkout of
the latest revision of the trunk is clearly missing files that were
within the range of revisions specified in the merge command that I
performed to accomplish this (bring the branch back into the trunk).
I simply don't know the best method of action at this point.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 17 19:19:44 2007