If you don't mind losing revision history, you would do something like
svn export all (I use tortoiseSVN for this task). Assuming that the
developer has the latest code and has everything checked out on their
machine, then you would do this:
Do a fresh checkout.
export all the files from the old working copy (the one with the higher
revisions) by using by right clicking and dragging in explorer and then
choosing svn export all.
Then copy that folder over to the freshly checked out working copy and
replace all.
Now you can check in your changes.
You can also just copy the 6 files you know are changed...
Russ
P.S. you can try to install svn 1.x binaries either on another box or
on the same box and try to dump the old repo again.
with Jeff S wrote:
> Hi Ruslan,
>
> Thank you for the prompt response!
>
> The binaries are long gone unfortunately. I did have
> another idea that might work?
>
> The last person who commited, will have all the
> latest code on their machine. So we can update
> the repository by having them:
>
> 1. Make another directory "c:\tmp\ccr" on your machine
> that we will call your update-copy.
> 2. Using Tortoise check out another working copy into
> that new folder you created above.
> 3. Copy over the files that were changed from the
> working copy into their matching folder locations
> in the update-copy.
> 4. Do another commit.
>
>
> Only six files were changed. So we would lose some
> revision levels but the repo would be updated. Does
> it sound like a good solution to you?
>
> Thanks, Jeff
>
> --- Ruslan Sivak <rsivak@istandfor.com> wrote:
>
>
>> Jeff,
>>
>> I'm not sure if there's an easier way to do this,
>> but I would use the
>> svn 1.0 binaries if you still had them, to dump the
>> old repo (only the
>> revisions since the ones you've loaded into the new
>> repo). You can then
>> load this incremental dump into the new repo.
>>
>> You might also want to use FSFS as the backend for
>> 1.4 as it is now the
>> preferred backend, and you will likely run into
>> similar trouble in the
>> future should you stay with Berkley db.
>>
>> Russ
>>
>> Jeff S wrote:
>>
>>> Moved from svn 1.0.x to 1.4. The dump file was
>>>
>> loaded
>>
>>> unto new svn. Other developers had commits that
>>>
>> were
>>
>>> not included in the dump file that was loaded for
>>>
>> the
>>
>>> new svn.
>>>
>>> They are now getting error that revisions are not
>>>
>> in
>>
>>> sync, and svn won't let me update.
>>>
>>> Tried to do another dump of orignal repo but the
>>>
>> new
>>
>>> install of svn complains that the version of
>>>
>> BerkelyDB
>>
>>> no longer matches - so I cannot get dump file.
>>>
>>> They are trying to commit at revison 2651 but the
>>> loaded svn repo is back at revision 2644. How can
>>>
>> I
>>
>>> force the svn repo or client working copy revision
>>> levels to match up for a commit? Or is there
>>> another way to handle this?
>>>
>>>
>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------
>
>>> To unsubscribe, e-mail:
>>>
>> users-unsubscribe@subversion.tigris.org
>>
>>> For additional commands, e-mail:
>>>
>> users-help@subversion.tigris.org
>>
>>>
>>>
>>
> ---------------------------------------------------------------------
>
>> To unsubscribe, e-mail:
>> users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail:
>> users-help@subversion.tigris.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 6 22:21:27 2006