subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Levy <andy.l...@gmail.com>
Subject Re: forbiden folders
Date Tue, 25 Oct 2011 17:33:07 GMT
On Tue, Oct 25, 2011 at 11:53, Robert J. Gebis <rjgebis@gmail.com> wrote:
>
> On Oct 25, 2011, at 10:28 AM, Andy Levy wrote:
>>
>> On Tue, Oct 25, 2011 at 11:23, Robert J. Gebis <rjgebis@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

Let's say that the file named "aux" exists in revisions 100 through
110 (IOW, you added it as "aux" in revision 100, and renamed it to
"misc" in 111). As long as you don't run svn co -r X or svn update -r
X where X is between 100 & 110, then you'll have no trouble.

>>
>> 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...

This can be done, but it's major surgery and invalidates all of your
working copies; you'll have to check out all new WCs. And there are
some cases where it may actually lead to an increase in space used by
the repository.

>>
>>> On Oct 25, 2011, at 9:48 AM, Andy Levy wrote:
>>>
>>>> On Tue, Oct 25, 2011 at 10:42, Robert J. Gebis <rjgebis@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."
>>>
>>>
>
>

Mime
View raw message