Thanks both of you for your help.
I know I can rename the file do the update then rename it back, but this
means that every user has to do it, and from experience some will not
and will come back blaming my team for their lack of attention to the
procedure we sent them. Hence the reason why I was looking for an
automated solution.
I love the fact that SVN deletes the files when they are removed from
the repository and this should remain the default. However, I would have
appreciated if there was a "special delete" to say that the client side
deletion is not required.
Ah well, I'll have to look around and find the most of these files, send
one procedure and hope for the best.
Thanks
Olivier
Ryan Schmidt wrote:
> To remove a file "foo" from the repository while keeping it in your
> working copy:
>
> cp foo foo.bak
> svn rm foo
> svn ci foo -m "removing foo"
> mv foo.bak foo
>
> For all other users, as Thomas says, if they have already modified
> foo, it will not be deleted during the update.
>
> For users who have not modified foo, the file will be deleted. They
> can either save it before doing the update:
>
> cp foo foo.bak
> svn up
> mv foo.bak foo
>
> Or if they forgot to do that, they can export it from the repository:
>
> svn export url://to/repo/foo_at_123 foo
>
> where "123" is a revision in which foo still existed.
>
>
> On Mar 28, 2008, at 11:42, Thomas Hemmer wrote:
>
>> after doing some research on your topic, I see two possible cases:
>>
>> 1. The working copy file has been modified by the user since he/she
>> checked it out.
>> Subversion is kind enough NOT to delete the file but simply transform it
>> into the "non-versioned" state.
>> This is exactly the behaviour that I would have expected, and it should
>> not hurt anyone since no changes are lost.
>>
>> 2. The working copy file has NOT been modified by the user since he/she
>> checked it out.
>> In this case SVN behaves somewhat rough (at least in my humble opinion)
>> and kicks away the WC file.
>> I personally would rather like the file to be handled according to (1),
>> too.
>> But your user still has the freedom to export that very file from the
>> last revision that still contained it and then use/edit it as he/she
>> likes.
>> So even this case shouldn't be regarded as a real disaster :-)
>>
>>
>>> We just did a migration from another SCM to SVN and we just
>>> discovered that some files in the repository should not have
>>> been there in the first place. Before the migration we
>>> spotted some of these already but unfortunately, a good
>>> number went through.
>>> I thought of deleting them with the "svn delete" command but
>>> in most cases, this is not desirable as it will mean the file
>>> is also deleted from the users working copies the next time
>>> they do an update. Indeed, these files, while they must not
>>> be in the repository, must stay on the users computers as
>>> they contain their own local options. Their contents may or
>>> may not be different from what currently is in the
>>> repository, but in all cases it will break compilation if
>>> they are removed.
>>> Recreating them can be quite cumbersome and considering the
>>> number of occurrences (number of files * number of users),
>>> I'm looking for a way to remove the file from source control
>>> so that it won't appear as modified on users machines while
>>> not deleting it at all.
>>> I have searched through the archives and found this post
>>> which is exactly what I need:
>>>
>>> http://subversion.tigris.org/servlets/ReadMsg?listName=users&m
>>> sgNo=51125
>>>
>>> However the proposed solutions work well if applied before
>>> the fact, but not when the file is already in the repository.
>>> Since this request was made quite a while ago, I'm wondering
>>> if anything changed in this area.
>>> If so, how can I achieve what I described above?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-01 13:51:45 CEST