[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: forbiden folders

From: Robert J. Gebis <rjgebis_at_gmail.com>
Date: Tue, 25 Oct 2011 10:53:45 -0500

On Oct 25, 2011, at 10:28 AM, Andy Levy wrote:
>
> On Tue, Oct 25, 2011 at 11:23, Robert J. Gebis <rjgebis_at_gmail.com> wrote:
>> Ok so this is the only way to get around this problem? Well dumping and reloading is another with rev range.
>> Does svnadmin tool support true "drop to revision". Or would it be possible?
>
> What's your goal? It sounds like you've already fixed the filename in
> the repository, so a checkout of HEAD (or any other revision that
> doesn't contain the bad filename) should work fine. Are you saying
> that this is not the case?
I did fixed this problem by dumping repo from 1to my last good version , dropping old repo creating new one and loading it back to new.
So I am good here. But this sure looks a long way there…. :) So looking for better solutions if possible.

> Just don't check out/update to that
> particular revision on Windows and you should have no trouble.
Not sure what you mean here? How can you skip specific update? and move on to later?
Little confused what you trying to say here

>
> Where you're having trouble right now is the fact that your update
> with "aux" failed. Try svn cleanup on your working copy, if that
> doesn't let you continue then you'll need to do a fresh checkout.

I did try svn cleanup and that did not help. I always do cleanup in any "strange" problems I encounter.
>
> You''ll have to explain what "drop to revision" means if you want to
> pursue that. Doing major surgery on your repository right now seems
> excessive to me.

Drop revision I mean using svnadmin (not svn for safety) and truly delete down from HEAD to lower revision. It is kind of what I did in a long walk by dumping -r 1:1001 and loading it back. Perhaps svnadmin trunk -r 1001 (1002 and 1003 would get truly removed).
Also I think this could be useful if you would want to backup rev 1 - 1000 and truncate 1-1000 to save space. This could be useful when long running project have a lot of changes and perhaps keeping all history might not be desirable. I know I know disks ar cheep and big these days :) Just idea...

Rev 1
    ...
Rev 1000
Rev 1001 - GOOD
Rev 1002
Rev 1003 - HEAD

>
>> On Oct 25, 2011, at 9:48 AM, Andy Levy wrote:
>>
>>> On Tue, Oct 25, 2011 at 10:42, Robert J. Gebis <rjgebis_at_gmail.com> wrote:
>>>> I did run into a problem that I was no aware of and I want to bring this up to attention. Also I would like to know what is the best way to handle such case since it gave me little problem.
>>>>
>>>> I am developing multi platform system. When I try to add "aux" folder on linux I was able to commit just fine. Now wen getting update on windows I was getting strange error saying that aux folder can't be created. Googling I found below link explaining reserved words on windows.
>>>>
>>>> http://www.blindedbytech.com/2006/11/16/forbidden-file-and-folder-names-on-windows/
>>>>
>>>> Now I try to move aux to misc on Linux and committing it. That was fine but still on windows I was not able to get latest.
>>>> It looks like it was updating all changes and (creation of aux) before applying (move aux mic).
>>>> I try to delete misc on linux and committing it. Still windows was complaining. It does not seems like svn have true "drop" to revision.
>>>>
>>>> I ended up doing svnadmin dump -r 1:$GOOD_VER, created new repo and loading it back. This is a long process.
>>>>
>>>> Are there any other/better alternatives. I was pressed on time so perhaps I did overlooked something?
>>>
>>> A fresh checkout (instead of trying to recover the half-updated one
>>> from your initial attempt, when the file was named aux) should work
>>> fine. If you check out HEAD, the client should never see the file
>>> named "aux."
>>
>>
Received on 2011-10-25 17:54:23 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.