Ok
Guys got to the bottom of this.
Things were happening that way because no one had told me the archive
recovery system incorporates a script (written by someone without any
documentation!!!) that automatically recovered the .svn files and
re-inserted them from a second archive when it expanded and imported the
primary archive (from which the svn files had been removed)!!! When I looked
at the script source I found it could be run with a "--no-svn" parameter to
get the archive recovered cleanly without the versioning.
There was clearly more to it than I or anyone else could have possibly
realized. My apologies for being so ***** off __> All I can say is that
there are over 6.000 files in the archive and their recovery (after the
fire) was critical - the stress was getting to me.
Once the script was run correctly there were no further problems in the
import routine.
Apologies
david
Mark Phippard-3 wrote:
>
> On 8/23/07, vizion <david@atf4.com> wrote:
>> Mark Phippard-3 wrote:
>> >
>> > On 8/23/07, vizion <david@atf4.com> wrote:
>> >>
>> >> I have a back up of thousands of files which we need to import into a
>> >> current
>> >> project. The files were orginally held on a server destroyed in a
>> fire.
>> >> The
>> >> back up copies were created by a process that removed the tmp/.svn
>> files.
>> >> If
>> >> I import them into a project (using eclipse radrails) the files still
>> >> have
>> >> versioning properties that confict with the versioning properties for
>> the
>> >> current project in the current repository (which is held on a local
>> >> freebsd
>> >> server using apache& mod_dav_svn).
>> >
>> > I do not understand what you mean. If the .svn files do not exist,
>> > then essentially it is like you have an exported copy of your
>> > repository. There is no versioning information. What exactly do you
>> > want to do? If you still have your repository, why do you need the
>> > files? Do they have modifications to them?
>> >
>> > You might be better off asking on the Subversion users@ list. More
>> > people to reach.
>> >
>> > I think you should try to phrase your problem better though so that
>> > you get the right help. Perhaps talk about what you have tried to do
>> > and what did not work.
>>
>> When files have been versioned they have properties which include the
>> version # and the name of the committer. So an attempt to include those
>> files in a different repository fails if the versioning properties. In
>> thsi
>> instance following an importing of the files into the project an attempt
>> to
>> commit those files to the depository fails with an error stating that the
>> .svm/tmp files could not be found. I am not exactly certain how this
>> works
>> but I believe the expected path to the .svn/tmp is part of the property
>> metadata. I thought anyone who was likely to know the answer would
>> understand the question rather than suggest I could explain the problem
>> better. It sounds like you blame me vecause you do not know the answer.
>
> Wow! Good luck.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
>
--
View this message in context: http://www.nabble.com/Files-from-another-repository-tf4318664.html#a12317373
Sent from the subclipse - users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Aug 24 20:06:36 2007