unable to checkout the source

I posted on the Google Code mailing list. Based on the error messages you sent, here's response that I got.

More than likely this developer is behind some sort of web-proxy that
doesn't understand WebDAV http requests (like REPORT or PROPFIND).

This message was edited 2 times. Last update was at 2008-01-24 15:57:50

yaragalla_murali wrote:I have tried as you said. I got the following error. Also attaching the modified scripts.
[...]

You can sync only the root of the repository, and not just the "trunk" subdir of it. Therefore, the "init" script failed, and then the "sync" script complained that the repository has not been initialized (as can be observed in the output you've provided).

So, you need to remove the "trunk" subdir. Change the corresponding line to:

After that, go to the step 3 from the "manual". It worked for me just a few minutes ago.

Hope this will finally work for you - you're really close to the full success

Michał Skrzypek

yaragalla_murali wrote:Hi I got it. I am able to run the scripts properly. Right now running the scripts and something is going on. will let you know by tomorrow morning about the complete result.

I'm really glad that you are this far. Anyway, please remember, that the connection will probably fail in the middle - then, just restart the "sync" script, it should resume from the right place.

Remember also, that introducing the "svn pdel" command moved the responsibility of NOT running multiple instances of the svnsync script from the script to the user - if you forget about that and fire up multiple instances simultaneously, the mirror repository will probably become corrupted.

Bye for now,
Michał Skrzypek

Jeff wrote:I posted on the Google Code mailing list. Based on the error messages you sent, here's response that I got.

More than likely this developer is behind some sort of web-proxy that
doesn't understand WebDAV http requests (like REPORT or PROPFIND).

The thing is, that the connection usually works, but breaks randomly (sic!), so I'd rather suggest, that it is the Google side we should blame

Regards,
Michał Skrzypek

Hi jeff, one small doubt. I am running the script2 and if it stops intermittently can I shutdown the PC and restart at later point of time. If I start at later point of time and if i run the script2 will it start from the place where it has stopped.

You said it does but just asking.

Although I am definitely not Jeff

, I can confirm that - this is the whole purpose of these scripts. The scripts are just simple sets of commands, and nothing in-between is stored in the memory, everything is on the disk (which is a non-volatile memory), so restarting the system is safe. You only need to later begin with starting the "server" script again, because the "sync" script relies on the loopback connection (with "localhost").

It is worth noting, that the "server" script runs a full-featured Subversion server, which means that you can connect with it as with any other Subversion server. The only (crucial) difference is that everything is stored locally. You should refer your svn client (be it Eclipse, Tortoise-SVN, or even the plain command 'svn co') to this server instead of googlecode's one (ie the address would be svn://localhost:23232/power-architect-svnsync/trunk), if you just want to checkout the latest version, or without "trunk" at the end to checkout the whole repository (much larger, but in fact everything is done locally, so it won't last very long).

Michał Skrzypek

Hi m--s, sorry for calling you jeff. ok I am clear in mind. will work with them and if any problem, will come back again.

This message was edited 1 time. Last update was at 2008-01-25 14:23:58

I got another response in the Google Code thread:

> I should point out that these users are able to start the checkout of
> source code, but will lose the connection partway through the checkout
> with errors like the one I posted earlier.

Oh! That's a very different story. If an http proxy were blocking
DAV requests, then the checkout would fail instantly.

> For now, they have resorted to using svnsync so that when they lose
> the connection, they can continue with svnsync where they left off,
> instead of having to restart the checkout everytime.

Uh, svnsync is a much much larger operation. Instead of just
downloading the latest changes, you're replicating the entire
repository's history. While svnsync is easily restartable, so is 'svn
checkout' and 'svn update'. Have they tried just running 'svn update'
when they get a disconnection to finish the update?

> Also, I don't know if this is related, but our development team is in
> Toronto, Canada, while one of these users is in Poland, and the other
> in India. Are there any known issues with code hosting in those areas?

No, there aren't any known issues, and I can't reproduce the problem
myself. It took me 11 minutes to checkout the whole trunk, but I
didn't see any disconnects.

Can you have them try the checkouts with a standard svn commandline
client? I'm wondering if the Subclipse plugin they're using is the
unofficial java-implementation of the svn client (SVNKit), rather than
the javahl version that talks to the official svn C libraries. I'd
like to rule out SVNKit first.

For those who would like to keep track of the thread, it is available here:

http://groups.google.com/group/google-code-hosting/browse_thread/thread/5cdbbe7c03dcbeac

This message was edited 1 time. Last update was at 2008-01-25 16:39:35

[...] Uh, svnsync is a much much larger operation. Instead of just
downloading the latest changes, you're replicating the entire
repository's history. While svnsync is easily restartable, so is 'svn
checkout' and 'svn update'. [...]

I'd like to give a really simple answer to that: although it is a much larger operation, it gives me the comfort (sic!) of having everything locally, so I am not depending on anyone else (including the provider and Google). Also, further updates are really fast - and I have the whole history of the project, which makes for an excellent add-on to the documentation.

Anyway, as I view this as a very general issue with Subversion (I mean, WHY is it so complicated to just mirror the repository, especially in the world where backups are essential? - this would make a really good question to the Subversion developers), I would suggest you, the developers at PowerSQL, to move to distributed VCS Mercurial, where these problems will never even appear. Especially while you're trying to attract the community.

Among the DVCSs - why I'm recommending Mercurial? It is cross-platform (unlike Git, which only pretends to be working reliably under Windows), and it is also fast (unlike everything else other that Git, for example: Bazaar is slow as hell in the comparison, see one of the links below).

I can try to help you with moving to Mercurial if you wish (within a reasonable timeframe, as I'm quite busy right now).

Of course, Mercurial also has its disadvantages, but before answering, please read these:
http://www.opensolaris.org/os/community/tools/scm/history/
http://web.archive.org/web/20061207132429/http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html
http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html

Unfortunately, the screenshots of Mortal Kombat have been removed since form the 3rd link

Hope this all helps you understand my point of view,
Michał Skrzypek

This message was edited 1 time. Last update was at 2008-01-25 17:13:31

I almost found the MK3 screenshots from that 2nd link a bit too distracting while reading the article

I've noticed that in the OpenSolaris link, they're supporting both Subversion and a distributed solution, perhaps something we could do?

Interesting reading.. especially the Mozilla blog.

Although our project certainly isn't married to Google Code hosting or SVN, it would take a lot to convince me to move the project away. What reason do we have to stay with Google?

-Responsive support from the right people--the current thread about the connectivity problems is being handled by Ben Collins-Sussman
-We're already set up there.. there is infrastructure in place that would have to be re-built

Why SVN?

-Excellent docs available at http://svnbook.red-bean.com/
-Responsive support from the right people, who happen to be the same people behind Google Code Hosting
-Many potential new devs already know how to use it (or CVS, which is similar enough)
-Fisheye works with it. http://trillian.sqlpower.ca/fisheye/browse/power_architect
-Lots of other SCM tools work with it too--it's mainstream

Although I'm sure we could all benefit from using distributed version control, I have literally 12 competing priorities stopping me from working on the Architect right now. I haven't made a change to the Architect in more than two weeks, and next week isn't looking promising (Monday and Tuesday are already writeoffs). If I add "change project hosting location" and "switch to distributed version control" to my list at this point, I think my head would explode.

I think the bottom line is, as long as the friendly folks at Google Code Hosting remain responsive to our questions and concerns, it would be foolish of me to contemplate switching away. Why walk away from a good situation?

Speaking of which, please feel free to join in on our GCH support thread (Jeff posted a link to it earlier). I would definitely like to get to the bottom of this connectivity problem. If you and Yaragalla are both having trouble checking out the code, there's a good chance you're not alone!

-Jonathan

PS: Although I have every confidence that Google will not lose our source code, we have been using svnsync to keep a local mirror of the repositories for Architect, MatchMaker, and the library since day one. The update runs every night. It's nice to know there are now additional mirrors in Poland and India. You can't be too safe!

This message was edited 1 time. Last update was at 2008-01-25 18:13:30

Jeff wrote:[...]
I've noticed that in the OpenSolaris link, they're supporting both Subversion and a distributed solution, perhaps something we could do?

Just keep in mind, that in Subversion the history is linear, while in DVCSs it is represented as a DAG (directed acyclic graph, used instead of the weird "branches/tags/trunk' structure), so the conversion from Subversion to Mercurial is possible (and even supported by the Mercurial itself to some extend, but not very straightforward), it is only a one-way conversion.

Hence, if you want to support both, you will have to rely on the Subversion repository as the "golden master", and it is A Bad Thing (TM), at least in my opinion (personally, I really don't like dealing with the whole "branches/tags/trunk" hell from the Subversion, along with its 'intelligent' line-endings conversions between platforms). Still, it is of course better than the current situation, and it has its advantages (broader range of tools supporting this, etc).

A screenshot with DAG within Mercurial GUI (shown after issuing the 'hg view' command) can be found on the Wikipedia page: http://en.wikipedia.org/wiki/Mercurial_(software). The interface there is a bit outdated, but it shows the concept well.

Regards,
Michał Skrzypek

This message was edited 1 time. Last update was at 2008-01-28 16:12:43

Jonathan, while I fully understand your concerns, it is also clear to me, that DVCSs are the "wave of the future" - you cannot avoid these in the long run anyway. At least, when you consider, that in a long run there will be a large community behind your projects, actively developing in parallel.

Using Subversion delays decentralization, and while right now it isn't that obvious (because there are mainly commits form within your company), sooner or later you'll have to move away from the centralized model.

Anyway, I don't want to drag you off your hard work, so there is this one last link, just in case you missed it, and then I'll shut up (I promise!)

. It is with Linus Torvalds visiting Google, and talking about Subversion, Git and DVCSs in general, really worth watching:

http://www.youtube.com/watch?v=4XpnKHJAok8

If this will not convince you, nothing will... Also, to spice it up a little

, here is just one sentence from this video: "... Subversion has been the most pointless project ever started", roughly at 3:30.

Bye,
Michał Skrzypek

Hi m--s, still I have not succeded yet in creating a full mirror. It connects to the repo and after some time it says "200 ok connection lost". I had restarted it for few times and i got the same error message. So I think I have to try hard. Today I will try again. Hope I will succeded.

Hi Jonathan, you always talk about support from google. I always think in mind , Why jonathan worries a lot about this. If you move to a stable version control and if you dont have any problem, why do you need lot of support? Any way it is up to you. Really very much unhappy about the google thing. I think there are few more people who tried to check out, failed and left. If google is this unstable for sure you will loose many developers who are really interested and got frustrated with these issues.

Hi m--s, I tried to open the link "www.youtube.com/watch?v=4XpnKHJAok8 " but it says the requested resource not found. I am also interested in reading the article.

Just saying I trid with sorce forge. It just took few seconds to checkin or to checkout the code. Painless. I am not suggesting sorceforge but it should be something like that. I think google people are trying to reproduce the problem on high spped networks which might not happen.

Hi yaragalla,

Just a quick question. Do you recall which command-line client you used to try to access the repository?

Thanks.