On Tue, Oct 25, 2011 at 14:01, Robert J. Gebis <rjgebis_at_gmail.com> wrote:
>
> On Oct 25, 2011, at 12:33 PM, Andy Levy wrote:
>
>> On Tue, Oct 25, 2011 at 11:53, Robert J. Gebis <rjgebis_at_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_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
>>
>> 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.
>>
> it is Folder not a File if that makes difference just to be clear… :) But is I want to update to the latest lets say -r 115 on windows talking all changes I will have problem… Correct? If that is the case the only way around it to dump/load or checkout fresh version?
You could try it and find out.
You will not have a problem, because at revision 115 there is no
file/folder named "aux" anymore, is there? A checkout does not get
revision 0 and then sequentially apply each subsequent revision to it.
It only gets the state of the repository at the revision you've
checked out.
>>>>
>>>> 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.
>
> I was under impression that this will/could be major surgery. So this was a suggestion for future?
There is some very preliminary work & discussion underway to build a
more usable means by which items can be "obliterated" from the
repository history without having to perform the current steps. It's
not something to be rushed into because of how Subversion stores
things, and permanent removal of data from a system designed to *not*
have data removed from it needs to be done delicately.
> But I ma puzzled by your last statement "it might actually lead to increase in space". How it that possible?
> If I trunkate -r 1:3000 and leave 3000 to HEAD how would this increase size? I know this is the other case I am talking about here not the initial problem with aux. (possible other usage in svnadmin trunk)
The increase in space has to do with how Subversion implements copies.
IIRC, if you remove the "right" parts of your history, you can end up
with duplicated items instead of cheap copies, thus increasing the
space needed to store it.
>>>>> 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 20:10:58 CEST