Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 9:10 PM Tom Browder wrote: > > > > On Mon, Dec 10, 2018 at 19:45 Nico Kadel-Garcia wrote: >> >> On Mon, Dec 10, 2018 at 5:56 AM Tom Browder wrote: >> > >> > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia >> > wrote: >> > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: >> > ... >> > > > Given that history will be lost, does anyone see any problems with my >> > > > recovery plan? >> > ... >> > > If you have working copies and you don't care about history, why are >> > > you spending any cycles on doing anything with hotcopy? You've lost >> > > history anyway, why keep any of it? >> > >> > Cycles aren't important, but the size of the data is. Transferring the >> > working copy from scratch would take a LONG time, while the bulk of >> > the data are already there in the hotcopy. >> >> Under what possible conditions wound importing a single snapshot of >> the current working copy, without history, take more time than working >> from a hotcopy to overlay the changes on top of that hotcopy? > > > I don’t know, Nico, I am a real novice at this. Your first answer didn’t help > because I didn’t know the ramifications of what I was trying to do. > > The original data, from just six months ago, was about 27 Gb, which took a > very long time to upload from my home computer to my remote server. Since > the only hotcopy, done shortly after the repo was loaded, there has been very > little change, so if I could start with the hotcopy and somehow synch my > working copy without pushing 27 Gb again, life would be better. ??? An import of the copy of the working data has no history. Is the *data* 27 GB, with no .svn content, 27 GB ? What in the devil are you putting in source control? I'm not objecting to your situation, just really confused by the content you are dealing with.
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 19:45 Nico Kadel-Garcia wrote: > On Mon, Dec 10, 2018 at 5:56 AM Tom Browder wrote: > > > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia > wrote: > > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder > wrote: > > ... > > > > Given that history will be lost, does anyone see any problems with > my recovery plan? > > ... > > > If you have working copies and you don't care about history, why are > > > you spending any cycles on doing anything with hotcopy? You've lost > > > history anyway, why keep any of it? > > > > Cycles aren't important, but the size of the data is. Transferring the > > working copy from scratch would take a LONG time, while the bulk of > > the data are already there in the hotcopy. > > Under what possible conditions wound importing a single snapshot of > the current working copy, without history, take more time than working > from a hotcopy to overlay the changes on top of that hotcopy? I don’t know, Nico, I am a real novice at this. Your first answer didn’t help because I didn’t know the ramifications of what I was trying to do. The original data, from just six months ago, was about 27 Gb, which took a very long time to upload from my home computer to my remote server. Since the only hotcopy, done shortly after the repo was loaded, there has been very little change, so if I could start with the hotcopy and somehow synch my working copy without pushing 27 Gb again, life would be better. Howver, it sounds like there is no way around a massive upload again :-( Thanks. -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 5:56 AM Tom Browder wrote: > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: > ... > > > Given that history will be lost, does anyone see any problems with my > > > recovery plan? > ... > > If you have working copies and you don't care about history, why are > > you spending any cycles on doing anything with hotcopy? You've lost > > history anyway, why keep any of it? > > Cycles aren't important, but the size of the data is. Transferring the > working copy from scratch would take a LONG time, while the bulk of > the data are already there in the hotcopy. Under what possible conditions wound importing a single snapshot of the current working copy, without history, take more time than working from a hotcopy to overlay the changes on top of that hotcopy? > So, again, would my plan work to re-establish my repo and work flow? Yes, any of your solutions could work. > Thanks. > > -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 15:56 Stefan Sperling wrote: ... Thank you, Stefan! Best regards, -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 03:37:46PM -0600, Tom Browder wrote: > On Mon, Dec 10, 2018 at 4:55 AM Tom Browder wrote: > > > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: > > ... > > > > Given that history will be lost, does anyone see any problems with my > > > > recovery plan? > > ... > > > If you have working copies and you don't care about history, why are > > > you spending any cycles on doing anything with hotcopy? You've lost > > > history anyway, why keep any of it? > ... > > So, again, would my plan work to re-establish my repo and work flow? > > Ping? I really need some expert opinion here so I can proceed: is my > plan to replace the lost repos with their hotcopies okay? > > Thanks. > > -Tom Your current working copy will be invalidated if repositories are back-dated. The SVN client will complain that it cannot find revisions which are not present in the old hotcopy. So if you use the old hotcopy, you need to check out a fresh working copy and then move your current files from your current working copy over to the fresh working copy, record any tree structure changes with 'svn add', 'svn remove', or 'svn move' as appropriate, and then commit the result. This giant commit will then contain a combined version of all the commits you have lost. Then you can continue working with SVN as usual.
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 4:55 AM Tom Browder wrote: > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: > ... > > > Given that history will be lost, does anyone see any problems with my > > > recovery plan? > ... > > If you have working copies and you don't care about history, why are > > you spending any cycles on doing anything with hotcopy? You've lost > > history anyway, why keep any of it? ... > So, again, would my plan work to re-establish my repo and work flow? Ping? I really need some expert opinion here so I can proceed: is my plan to replace the lost repos with their hotcopies okay? Thanks. -Tom
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling wrote: > Perhaps Github's customers will just need to press a little bit > harder for a fix to be applied at Github's end? Agreed. The squeaky wheel gets the grease.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 10.12.2018 10:08, Thorsten Schöning wrote: > Guten Tag Branko Čibej, > am Sonntag, 9. Dezember 2018 um 19:27 schrieben Sie: > >> My current thinking is that if GitHub can't fix their protocol emulation >> by the time of the planned Subversion 1.12 release, we'll have to >> seriously consider including this patch. > If they really didn't fix it until 1.12, they surely won't ever > anymore. Maybe this gives you enough time to discuss this > fundamentally and tell people what they can expect for issues like > this one in future from the SVN-team? > > It seems clear to me that the issue would need to be fixed by GH, but > your are able to workaround it somewhat easily. But this is only one > issue, what in case of another one easy like this or more difficult? Exactly, this is why I'd prefer not to implement a specific hack for GitHub in our code. If we made it a policy to support one broken server, everyone would expect us to do so for the N+1st broken server, too ... it's simply unmanageable in the long run. > In theory 1.12 could break something different for some reason and > people would need to stick with 1.10 for at least a year then. Ah, but we have a test in our test suite now (for this particular case). :) > If you come to the conclusion that you don't do this kind of hacking > anymore Just to point out: it' snot "any more"; we've never had any vendor-specific hacks in our code. Well actually that's not quite true, we still have a (build-time) hack for Microsoft's ASP.Net, which could not abide having the '.svn' directory in its project tree; but that was a client-side, compile-time hack for a misfeature that had no workaround. > or even at all including this issue, users of the SVN-bridge > would simply need to change their workflow to something else. I'm > only using the bridge because it was the easiest way to stay with my > former workflow and how I manage some versioned libs. > > Or do you think it's not worth discussing that fundamentally (yet)? It is surely worth discussing, but please, such discussions really should happen on our dev@ list, not the users@ list. Feel free to start a thread there. -- Brane
Re: Subversion Exception!
Let me translate it for English people. > >-Original Messages- >From:"为呐☆而狂" >Sent Time:2018-12-09 01:01:49 (Sunday) >To: users >Cc: >Subject: [CASS SPAM]Subversion Exception! > >Hello: > > I installed Tortoise SVN in the C:\Program Files\TortoiseSVN directory, but > it was not loaded into the D disk at all. How can I report this error? > > > --- > Subversion Exception! > --- > Subversion遇到了一个严重的问题。 Subversion encountered a serious problem. > 麻烦您花点时间将这个问题报告给Subversion Please report this issue to Subversion > 请尽量详细的描述您之前尝试的操作。 Please describe the steps that you did. > 不过希望您先在邮件存档中搜索一下同样的问题，避免重复提交。 Before report this issue, please search archive for avoid reporting same issue. > 您可以登录下面的地址搜索邮件存档： You can search archive in following location: > http://subversion.apache.org/mailing-lists.html > > Subversion产生的报告如下 > (您可以用Ctrl-C快捷键复制 > 本对话框的内容到剪切板)： Following is outputs that Subversion generated: > > 文件 > > “D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_wc\wc_db.c”，行 > > 9210：断言失败(svn_dirent_is_absolute(local_abspath)) “D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_wc\wc_db.c”，Line 9210：Assertion failed(svn_dirent_is_absolute(local_abspath)) > --- > 确定 Confirm > ---
Subversion Exception!
Hello: I installed Tortoise SVN in the C:\Program Files\TortoiseSVN directory, but it was not loaded into the D disk at all. How can I report this error? --- Subversion Exception! --- Subversion?? ??Subversion ?? ?? ?? http://subversion.apache.org/mailing-lists.html Subversion?? (Ctrl-C?? ??)?? ??D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_wc\wc_db.c?? 9210??(svn_dirent_is_absolute(local_abspath)) --- ---
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: ... > > Given that history will be lost, does anyone see any problems with my > > recovery plan? ... > If you have working copies and you don't care about history, why are > you spending any cycles on doing anything with hotcopy? You've lost > history anyway, why keep any of it? Cycles aren't important, but the size of the data is. Transferring the working copy from scratch would take a LONG time, while the bulk of the data are already there in the hotcopy. So, again, would my plan work to re-establish my repo and work flow? Thanks. -Tom
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Dec 10, 2018 at 10:08:10AM +0100, Thorsten Schöning wrote: > If you come to the conclusion that you don't do this kind of hacking > anymore or even at all including this issue, users of the SVN-bridge > would simply need to change their workflow to something else. I'm > only using the bridge because it was the easiest way to stay with my > former workflow and how I manage some versioned libs. > > Or do you think it's not worth discussing that fundamentally (yet)? Perhaps Github's customers will just need to press a little bit harder for a fix to be applied at Github's end? As Branko explained earlier, the fix amounts to sending another HTTP header in the response. Github's web developers should be able to manage that...
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Branko Čibej, am Sonntag, 9. Dezember 2018 um 19:27 schrieben Sie: > My current thinking is that if GitHub can't fix their protocol emulation > by the time of the planned Subversion 1.12 release, we'll have to > seriously consider including this patch. If they really didn't fix it until 1.12, they surely won't ever anymore. Maybe this gives you enough time to discuss this fundamentally and tell people what they can expect for issues like this one in future from the SVN-team? It seems clear to me that the issue would need to be fixed by GH, but your are able to workaround it somewhat easily. But this is only one issue, what in case of another one easy like this or more difficult? In theory 1.12 could break something different for some reason and people would need to stick with 1.10 for at least a year then. If you come to the conclusion that you don't do this kind of hacking anymore or even at all including this issue, users of the SVN-bridge would simply need to change their workflow to something else. I'm only using the bridge because it was the easiest way to stay with my former workflow and how I manage some versioned libs. Or do you think it's not worth discussing that fundamentally (yet)? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
