On Wednesday 17 January 2007 11:31, Craig White wrote:
> 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, it almost sound like you thought you successfully reverted your
changes back to r49, so I'll warn you that once you've committed a
change (i.e. 139), then it does NOT allow you to simply undo that
change from the repository. If you use 'svn update -r 49' then you
are only asking to see that version. If you made changes to that and
tried to submit them, it would complain that the files need to be up
to date because it could only add new changes to the latest revision
(139).
I am wondering if the root of your problem is that those new
files/folders were not committed after merging. The merge only copies
the changes into the working folder. After you commit that working
folder with the merged changes, then it creates r139 (or 140 if there
was already a 139 committed), and that rev is the merge.
I think you're just trying to see things more complicated than they
are. This should all make sense if you understand how amazingly
simple the whole revision thing works, at least to the user.
---------------------------------------------------------------------
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:54:56 2007