You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jojakim Stahl <jo...@jojakim.de> on 2011/12/15 11:54:36 UTC
why does svn upgrade contact the server?
Hi all!
Before several years we had a HDD crash and lost part of our svn history.
Now we have old projects (we have many customer-individual projects) where
we only have the working copy. This WC refers to an old svn server, it
cannot be switched because the WC head revision has been lost. Till svn 1.6
we could use svn diff to see changes that we implemented after the initial
crash. With 1.7 this doesn't work anymore because svn refuses to upgrade the
WC because it cannot contact the old server.
I found that here http://blogs.collab.net/subversion/ (section "Subversion
1.7 Q & A, part 1") is stated regarding svn upgrade: "This is a local
metadata storage change only, though. 'svn upgrade' does not contact the
server and does not modify the content of the users' working files."
So why my svn tries to contact the server at all?
Thanks
Jojakim
Re: why does svn upgrade contact the server?
Posted by Les Mikesell <le...@gmail.com>.
I'd think the right thing to do here would be to import your pristine
directory under .svn as the start of a new repository, check it out
and copy over changes from the visible part of the working copy,
commit that, then work as normal. Anyone have a better idea or hints
on how to avoid unwanted metadata files while doing this?
--
Les Mikesell
lesmikesell@gmail.com
Re: why does svn upgrade contact the server?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Thu, Dec 15, 2011 at 12:37:00 +0100:
> 'svn upgrade' contacts the server when upgrading very old working
> copies which didn't store the repository root and UUID.
For the record, how old is "old" here? 1.5? 1.0?
Re: why does svn upgrade contact the server?
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 15.12.2011 15:26, schrieb Jojakim:
> As I explained in my initial post, we have many individual projects. They are
> usually not touched - sometimes for years - once they are installed and
> tested (industrial automation area). When we need to do major changes, yes,
> we import them in a new repo. But sometimes the changes are so small, that
> the work around (reorganizing - importing - etc) takes much more time then
> the modification itself and the customer does not agree to pay more. In these
> cases we do the changes in the WC directly.
Letting things sleep in a working copy, possibly even one that everyone
can access and modify without any log message, seems like a bad idea.
Version control is also about being able to retrace your steps and also
a bit about allowing others to retrace your steps.
I don't think there is anything clearer than creating a branch (URL-URL
copy), checking out a working copy, doing a few customer-specific
modifications and then committing that with a suitable comment. However,
that means you don't import them into a separate repository but that the
"main" project with all customer-specific live in the same repository.
That way also makes it easier to merge things between branches if you
want to, and it also reduces the amount of storage required, because
copies within a repository are size-optimized using representation sharing.
That said, I'm glad you solved your problem!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Re: why does svn upgrade contact the server?
Posted by Jojakim <jo...@jojakim.de>.
On 15.12.2011 13:25:58, Stefan Sperling wrote:
> I would recommend to use a 1.6 client instead of trying to upgrade the WC.
> And above all import the data into a new repository so it can be versioned
> properly again. Having a working copy as the only copy of the data was
> bound to cause a dead-end situation at some point.
>
>
As I explained in my initial post, we have many individual projects. They are
usually not touched - sometimes for years - once they are installed and
tested (industrial automation area). When we need to do major changes, yes,
we import them in a new repo. But sometimes the changes are so small, that
the work around (reorganizing - importing - etc) takes much more time then
the modification itself and the customer does not agree to pay more. In these
cases we do the changes in the WC directly.
Thank you guys for your help to solve my problem.
Jojakim
Re: why does svn upgrade contact the server?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 15, 2011 at 12:04:31PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@elego.de> writes:
>
> > You will likely be better
> > of with a new checkout, given that such old working copies often exhibit
> > problems during or after an upgrade to the 1.7.x format anyway.
>
> That's not possible as the repository effectively no longer exists.
Ah, I realise that now. Sorry, I skimmed the initial email too fast.
> However it is possible to manually add enough information to make the
> client attempt the upgrade. (If the working copy has any of the
> corruption Stefan mentioned then the upgrade may still fail.)
I would recommend to use a 1.6 client instead of trying to upgrade the WC.
And above all import the data into a new repository so it can be versioned
properly again. Having a working copy as the only copy of the data
was bound to cause a dead-end situation at some point.
Re: why does svn upgrade contact the server?
Posted by Jojakim <jo...@jojakim.de>.
On 15.12.2011 13:04:30, Philip Martin wrote:
> The most likely thing to be missing is the root URL.
That was it. After fixing entries it worked.
Thank you!
Jojakim
Re: why does svn upgrade contact the server?
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> You will likely be better
> of with a new checkout, given that such old working copies often exhibit
> problems during or after an upgrade to the 1.7.x format anyway.
That's not possible as the repository effectively no longer exists.
However it is possible to manually add enough information to make the
client attempt the upgrade. (If the working copy has any of the
corruption Stefan mentioned then the upgrade may still fail.)
The most likely thing to be missing is the root URL. You only need to
add this for the single entry that represents the root of the working
copy and you will find that in the .svn/entries file in the root of the
working copy. If your .svn/entries file is XML then locate the root
entry:
<entry
...
name=""
...
url="http://example.com/some/repos/trunk"
...
revision="6">
and add a repos element:
<entry
...
name=""
...
url="http://example.com/some/repos/trunk"
repos="http://example.com/some/repos"
...
revision="6">
If your .svn/entries file is not XML then it should start something like:
10
dir
6
http://example.com/some/repos/trunk
2011-12-15T10:15:25.161943Z
Change the blank line after the checkout URL to define the root URL:
10
dir
6
http://example.com/some/repos/trunk
http://example.com/some/repos
2011-12-15T10:15:25.161943Z
Make sure you change the blank line, do not insert a new line.
--
Philip
Re: why does svn upgrade contact the server?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 15, 2011 at 11:54:36AM +0100, Jojakim Stahl wrote:
> Hi all!
>
> Before several years we had a HDD crash and lost part of our svn history.
> Now we have old projects (we have many customer-individual projects) where
> we only have the working copy. This WC refers to an old svn server, it
> cannot be switched because the WC head revision has been lost. Till svn 1.6
> we could use svn diff to see changes that we implemented after the initial
> crash. With 1.7 this doesn't work anymore because svn refuses to upgrade the
> WC because it cannot contact the old server.
>
>
> I found that here http://blogs.collab.net/subversion/ (section "Subversion
> 1.7 Q & A, part 1") is stated regarding svn upgrade: "This is a local
> metadata storage change only, though. 'svn upgrade' does not contact the
> server and does not modify the content of the users' working files."
>
> So why my svn tries to contact the server at all?
'svn upgrade' contacts the server when upgrading very old working
copies which didn't store the repository root and UUID. This information
must be stored in the 1.7 format so it needs to be retrieved from the
server if not already cached by the local working copy meta data.
Early versions of Subversion did not cache this data locally.
Your working copies must be several years old. You will likely be better
of with a new checkout, given that such old working copies often exhibit
problems during or after an upgrade to the 1.7.x format anyway.
Mostly because of meta-data corruption which can lurk undetected in 1.6
and ealier working copies for a long time (due to the data being
distributed across many files and directories some of which are rarely
accessed). Such problems are uncovered when trying to convert the working
copy to the 1.7 format.
Re: why does svn upgrade contact the server?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Jojakim Stahl,
am Donnerstag, 15. Dezember 2011 um 11:54 schrieben Sie:
> Till svn 1.6
> we could use svn diff to see changes that we implemented after the initial
> crash.
Does this mean you worked on the working copy and just never
committed? You could have created a new repository with the contents
of the working copy at least and start a new history for your work.
That's what I would have done and do now in your case: start a clean
new repository with the working copy as initial data.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow