On Jan 14, 2006, at 15:01, Lieven Govaerts wrote:
>> We have a project (containing multiple subdirectories and
>> files therein) called /trunk/project that someone on the
>> team--unfortunately--exported from, made some changes to,
>> then imported back in as /trunk/project1.
>> Turns out we like what they did and now just want to "slam
>> over the top of" /trunk/project with /trunk/project1 and make
>> /trunk/project1 go away (delete it), so that the new
>> /trunk/project will be our codebase going forward and we'll
>> have all the previous history still there if we want it.
>>
>> Doesn't seem like merge is what we want, as we just want a
>> direct replacement of /trunk/project with /trunk/project1.
>> Also I don't think we want to delete /trunk/project and
>> rename /trunk/project1 to /trunk/project is what we want
>> either, as then we lose the history in (the original)
>> /trunk/project...
> a merge can't work here, since the files in trunk/project1 are
> considered new and not related to those in trunk/project ( even if
> they have the same name ).
That's not a reason for a merge not to work. Merge just means "Take
the difference between A and B, and apply it to C." Doesn't matter if
A and B have the same ancestry or not.
> In your situation I would make sure that the changes on
> /trunk/project1 would be re-applied to your original /trunk/project
> as a changeset.
That's what I'd do too, and I'd use svn merge to do it. Discover (by
asking the person who originally made the export, or, if they don't
know, then by analyzing the project1 code and comparing it to known
states of project) the revision of project's trunk upon which the
project1 changes were based. Call this X. Now get a working copy of
trunk as it is in the repository now. Now do this:
svn merge \
url://to/repository/trunk/project_at_X \
url://to/repository/trunk/project1_at_HEAD \
.
That should mean: "Take the changes that occurred between project at
revision X and project1 as it is now, and apply these to the current
working copy of project's trunk."
Then you test the working copy, make sure it's as you want, then you
commit, stating you merged in in the project1 changes. Then you can
delete project1 from the repository.
And educate your "someone" on the proper use of feature branches to
avoid this mess in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 14 20:56:36 2006