svn problems
Albert Graef
CEST I'm only getting "svn: Temporarily unavailable" errors from Google
Code.
Eddie, Jiri, have you tried committing anything to pure-lang svn lately?
Does it work for you? (If you try now, please log in to get the new
commit password from http://code.google.com/p/pure-lang/source/checkout,
after logging in to Google Code. I generated a new password since I
thought it might help. It didn't.)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Neuhauser, Roman (GE Capital, consultant)
> Bad news: I can't commit anything to svn any more. :( Since around 12:45
> CEST I'm only getting "svn: Temporarily unavailable" errors from Google Code.
>
> Eddie, Jiri, have you tried committing anything to pure-lang svn lately?
> Does it work for you? (If you try now, please log in to get the new commit password from
> http://code.google.com/p/pure-lang/source/checkout,
> after logging in to Google Code. I generated a new password since I thought it might help. It didn't.)
checkout still works?
Jiri Spitz
>
> Eddie, Jiri, have you tried committing anything to pure-lang svn lately?
> Does it work for you? (If you try now, please log in to get the new
> commit password from http://code.google.com/p/pure-lang/source/checkout,
> after logging in to Google Code. I generated a new password since I
> thought it might help. It didn't.)
>
I think passwords are private for individual users - there is no need
for other users to change them.
Jiri
Albert Graef
> checkout still works?
Yep. I actually checked out a new working copy over https, that works,
but commits from the new wc fail just as well.
Looks like other people are seeing this issue, too
(http://code.google.com/p/support/issues/detail?id=3984), so there's
hope that someone will eventually fix it, I guess.
Just for the record, my own report is at
http://code.google.com/p/support/issues/detail?id=4579, so that you can
all "star" it and make it go up on the list. ;-)
Well, if GC becomes the next SourceForge now (I still recall those
horrors, with the sf.net mailing lists and cvs/svn being down every
other week, sometimes for days), where to move next? github??
Albert Graef
> Checkout works, commit failed (temporary unavailable).
Thanks for checking. So it's not just me, that's good to know.
> I think passwords are private for individual users - there is no need
> for other users to change them.
Thanks, I didn't remember that.
Neuhauser, Roman (GE Capital, consultant)
> Well, if GC becomes the next SourceForge now (I still recall those
> horrors, with the sf.net mailing lists and cvs/svn being down every
> other week, sometimes for days), where to move next? github??
the point of DVCSs is that such question is largely irrelevant.
--
roman
Albert Graef
Yes sure, that's why we want to have one for pure-lang, we agree on that. :)
BTW, svn seems to be back to normal again. At least I could commit my
stuff without problems now. But I'll look into migrating to Hg asap.
Libor
Neuhauser, Roman (GE Capital, consultant)
> Neuhauser, Roman (GE Capital, consultant) wrote:
> > the point of DVCSs is that such question is largely irrelevant.
>
> Yes sure, that's why we want to have one for pure-lang, we
> agree on that. :)
my innuendo was too subtle. ;) let me be blunt: i'd consider moving the source
out of GC, into whatever DVCS (git, hg) and hosting (github, bitbucket).
the rest of the project infrastructure could stay at GC if the mixed solution allowed
for sufficient integration, or you could move it wholesale (which you already mentioned).
--
roman
Morgan Sutherland
--
You received this message because you are subscribed to the Google Groups "pure-lang" group.
To post to this group, send email to pure...@googlegroups.com.
To unsubscribe from this group, send email to pure-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pure-lang?hl=en.
Albert Graef
> Any organisation, beyond certain size, becomes incompetent.
Well, they fixed it promptly when it got reported. And so far this was
the only major hiccup since I've moved pure-lang there. So I must say
that I've been quite happy with GC so far. SF was getting much worse
before I decided that I had enough of it.
Albert Graef
> my innuendo was too subtle. ;) let me be blunt: i'd consider moving the source
> out of GC, into whatever DVCS (git, hg) and hosting (github, bitbucket).
> the rest of the project infrastructure could stay at GC
Yes, I've thought about this too. But having repo, downloads and wiki at
one single provider is convenient and makes the project easier to manage
for me. Moving everything to github/bitbucket would be an option, but
switching providers is always a hassle, so until GC starts getting
really shoddy I'm not jumping ship just yet.
Albert Graef
> Moving the codebase to github would give the project more
> visibility/credibility in the hip hacker scene. As my web-programmer
> friend once told me, some companies won't even look at your resume if
> you don't have a github account.
Well, some companies may consider fluency with git an absolute must,
just as they may require you to know C++ or Java very well. But
assessing your hacker creds by checking for a github account? Come on.
I think that if you know any kind of vcs, then you can learn the basics
of git or any other dvcs (i.e., enough to use it for the everyday
maintenance tasks) in an afternoon. I started using it right away after
reading some manpages, although I bought Scott Chacon's "Pro Git" book
now to come to grips with the more advanced features. In any case, I
wouldn't consider this really hard compared to, say, learning Haskell
when all you know is Fortran. ;-)
> I, personally, prefer the github interface to Google Code or Bitbucket.
Yes, github looks nice to me, too. I'd certainly consider it if I were
to start a new project. But, as you say, it's a matter of preference and
workflow habits. I happen to like GC and its no-frills all-in-one
approach, too, it makes maintaining a small project very easy. And
moving a project is always a hassle for both maintainers and users, so
I'd really like to avoid that if possible.
> Moreover, git has more critical mass at the moment than hg, so I would
> guess that using hg would result in more people having to use a system
> that they weren't using before.
That's true, but how hard can it be to learn one when you know the
other? GC supports hg, that's why I'm taking a look at it now. I don't
really know much about it yet (didn't have time to play with it), but
from what I've read so far it seems simpler than git in some ways.
Is anyone aware of any major technical shortcomings in Mercurial that I
should consider carefully before migrating the repo?
Albert
Morgan Sutherland
But assessing your hacker creds by checking for a github account? Come on.
I think that if you know any kind of vcs, then you can learn the basics
of git or any other dvcs (i.e., enough to use it for the everyday
maintenance tasks) in an afternoon.
--
Albert Graef
> I've definitely encountered the attitude that if it's not on Github, it
> github, it's more likely to be serious or at least active vs. GC or
> SF.)
Hmm, is GC really considered toy stuff these days? I was rather happy
that I could escape SF, and at the time GC seemed an obvious choice for
a project like this, it's just easy to use.
> Adoption, however, doesn't seem to be one of your priorities, so with
> that your reasoning is sound.
Well, I'm not out to market these things, but having more exposure would
certainly be a good thing, in order to attract more developers and
users. Migration to github seems easy, it looks like there's a
ready-made option to import an existing svn repo.
Does everyone else here confirm that it would be better to use github?
Other opinions?
Morgan Sutherland
Hmm, is GC really considered toy stuff these days?
at the time GC seemed an obvious choice for
a project like this, it's just easy to use
Ryan Schmidt
On Oct 28, 2010, at 11:40, Morgan Sutherland wrote:
>> Hmm, is GC really considered toy stuff these days?
>>
>
> No, not really – it's just not the hot new thing. SF vs. GC vs. Github have popularity roughly proportional to the VCS's they use:
>
> Everybody loathes CVS (SF)
> People are indifferent about SVN (GC)
> People are excited to use git (Github)
...for certain values of "people". I'm perfectly happy with Subversion. It's the only version control system I know, and I've used it for years and I know it pretty well, including its quirks. I'm not excited to use git or another system in the sense that I'm not excited to have to spend hours learning a new tool and discovering its peculiarities rather than doing actual work.
> GC seems to be a fine tool, but what's lacking are the social networking features – having a profile, 'following' projects, etc. As much as these things are frivolous, they do help to attract people. If people can do all their code stuff on one website and advertise their projects, they will be more likely to contribute. Moreover, when other people look at their profiles, they will see what projects they are working on, thus bringing visibility to those projects. It's all about leveraging vanity =P
I don't really like social networking features and I don't want yet another profile. Nevertheless, Google Code does already have a minimal one. Also, you can "star" projects on Google Code that you're interested in. Here for example is our illustrious leader's profile on Google Code where you can see his info and starred projects:
http://code.google.com/u/aggraef/
You can also click "Updates" to see what he's been working on.
Michael Ashton
On Oct 27, 7:26 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> Morgan Sutherland wrote:
> > I've definitely encountered the attitude that if it's not on Github, it
> > probably isn't serious.
> Does everyone else here confirm that it would be better to use github?
> Other opinions?
for me and loads of other people.
As far as I know, the technical advantage of Git is its filesystem
format; people say it's faster and scales better. Some people also
prefer the multiple small programs approach. I agree that's a nice
thing.
The advantages to Hg are that it's simpler to learn, has better
documentation (IMHO), and works better on Windows (last I checked --
these things can change quickly of course). Hg extensions must
generally be written in Python, which is good or bad depending on your
perspective. Hg's format is supposedly not as good (the Git people say
that), but it's used on very large projects too, so I'm not sure that
it's really all that bad. I have a large project on it at work, and it
does fine.
AFAICT the two systems are basically equivalent in terms of
capability. Some people may try to say otherwise, but I personally
don't see it. An extension for one tends to show up for the other.
The "cool hackers" definitely use git, probably because Linus Torvalds
wrote it. Personally, I'm not very cool, so I use Mercurial for most
of my stuff, including at work. This is mostly because I have to use
it on Windows sometimes, and it does very well in that situation.
Also, I find it a little easier to use (but not much). But there are
plenty of people out there who use both, on different projects. No
reason why you can't.
If you're allergic to Python, even when it's invisible and under the
hood, then maybe you won't like Mercurial so much. Also, if you want
to be accepted in circles of cool and hip Linux people, you should use
git. Otherwise I think it's a toss-up.
--mpa
Albert Graef
> No, not really � it's just not the hot new thing.
Frankly I don't care too much about that. I do care that the stuff that
I need works, though.
> Everybody loathes CVS (SF)
Note that SF has had svn for years, and it also offers git for some time
now. I think that people started hating SF because it got so slow, had
so many outages (especially around the time when they switched data
centers) and the file release system was a big pita. At least that was
my experience.
> If, however, it will be a significant pain to do so, perhaps it won't be worth it.
Well, the pain always needs to be measured relative to the pain of the
alternative. ;-)
If GC really starts grinding under its load, then I'll move the project
very quickly, I've done so before. I don't really think that this will
be the case, though. GC reportedly had some intermittent backend latency
problems lately for some yet undetermined cause. But if anyone knows how
to run a big server farm then it's Google, so I trust that they can fix
things.
The idea to move to github anyway, even without GC services failing,
seems to be quite controversial from what I've gleaned from the
discussion so far. I certainly don't want to alienate existing users
(some of whom have been using Pure, and Q before that, for years) or our
package maintainers, so I'm *not* going to press ahead with that no
matter what.
However, we really need to switch to distributed version control, I
fully agree with that. The recent outage just emphasized that point, but
in fact I've been thinking about that for months, and I'm going to
finally get serious about this now. I plan to take a closer look at Hg
this weekend.
Albert Graef
> I don't think it matters very much. I can recommend Hg on GC. Works
> for me and loads of other people.
Thanks for the detailed analysis. I'll definitively have a look at hg. I
like its similarity to the svn workflow, that should make it easy for
people to migrate from svn.
> AFAICT the two systems are basically equivalent in terms of
> capability. Some people may try to say otherwise, but I personally
> don't see it.
Git's staging area (the index) maybe? That's a powerful feature, but it
also adds complexity, of course.
> This is mostly because I have to use
> it on Windows sometimes, and it does very well in that situation.
That's an important point. I'd hate it if I had to copy the source over
to Windows manually in order to test my stuff there. I'm currently using
TortoiseSVN for that.
I see, however, that there are new downloads and lots of bugfixes at the
TortoiseGit project, too. Has anyone used that recently? Maybe it has
improved lately?
> If you're allergic to Python, even when it's invisible and under the
> hood, then maybe you won't like Mercurial so much.
I don't care what's under the hood as long as it works and is widely
available. And the speed seems to be ok.
Albert Graef
> I'm not excited to use git or another system in the sense that I'm not excited to have to spend hours learning a new tool and discovering its peculiarities rather than doing actual work.
Ryan, would it be a big problem if you had to use hg to grab the latest
development sources of Pure? It seems that the commands you use for the
usual stuff are pretty similar to svn.
I think we really need to go for a DVCS. It offers some real advantages
for both maintainers and users. I hope that using hg will ease the pain
of having to learn a new tool (and of course I will then put up some
instructions for svn users to help with that).
Ryan Schmidt
On Oct 28, 2010, at 21:09, Albert Graef wrote:
> Ryan Schmidt wrote:
>> I'm not excited to use git or another system in the sense that I'm not excited to have to spend hours learning a new tool and discovering its peculiarities rather than doing actual work.
>
> Ryan, would it be a big problem if you had to use hg to grab the latest
> development sources of Pure? It seems that the commands you use for the
> usual stuff are pretty similar to svn.
>
> I think we really need to go for a DVCS. It offers some real advantages
> for both maintainers and users. I hope that using hg will ease the pain
> of having to learn a new tool (and of course I will then put up some
> instructions for svn users to help with that).
I absolutely don't mind; do what you think is best for pure. I just probably won't convert my own development stuff from svn just yet. :)
Roman Neuhauser
> Neuhauser, Roman (GE Capital, consultant) wrote:
>
> > my innuendo was too subtle. ;) let me be blunt: i'd consider moving the source
> > out of GC, into whatever DVCS (git, hg) and hosting (github, bitbucket).
> > the rest of the project infrastructure could stay at GC
>
> Yes, I've thought about this too. But having repo, downloads and wiki at
> one single provider is convenient and makes the project easier to manage
> for me. Moving everything to github/bitbucket would be an option, but
> switching providers is always a hassle, so until GC starts getting
> really shoddy I'm not jumping ship just yet.
not "move the source".
--
roman
Albert Graef
> I absolutely don't mind; do what you think is best for pure.
Ok, thanks. As there's been no other complaints about that, I'll go
ahead with it.
> I just probably won't convert my own development stuff from svn just yet. :)
I understand. But as you're also maintaining quite a few ports over at
MacPorts, I guess that you'll have to come to grips with git and/or hg
soon enough anyway. ;-) Many projects are using them now.
Roman Neuhauser
> I'm perfectly happy with Subversion. It's the only version control system
> I know, and I've used it for years and I know it pretty well, including its
> quirks. I'm not excited to use git or another system in the sense that I'm
> not excited to have to spend hours learning a new tool and discovering
> its peculiarities rather than doing actual work.
svn
almost exclusively (with cvs bits) until two years ago when i went to
hg. one of hg's selling points was its CLI's similarity to svn/cvs.
my
fear of retraining costs quickly faded as i started using it, and the
benefits that could be reaped from day one were such that i never
looked
back, even for my small single-developer efforts.
--
roman
Roman Neuhauser
> On Oct 27, 7:26 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> > Does everyone else here confirm that it would be better to use github?
> > Other opinions?
>
> I don't think it matters very much. I can recommend Hg on GC. Works
> for me and loads of other people.
installation, and you may spend days or weeks trying to integrate it
with
other python stuff you might want to use it with (binary compatibility
is a bitch).
i understand that TortoiseHg, the most popular (seems to me)
point'n'click
facade to hg bundles *its* own hg, ignoring both the "normal" python
*and*
the "normal" hg you might have installed. this probably only affects
people
who have above-standard or otherwise unusual requirements; two years
ago
the unsual requirements included converting a svn repository (i had to
do it
on freebsd).
> As far as I know, the technical advantage of Git is its filesystem
> format; people say it's faster and scales better.
mozilla)
repositories or checkouts, and really only a little experience with
git at all,
so for me the most interesting facet was the index. it can be
approximated
with hg, just not so comfortably.
> The advantages to Hg are that it's simpler to learn, has better
> documentation (IMHO), and works better on Windows (last I checked --
> these things can change quickly of course).
cygwin at that time (today it comes with bundled MSYS). i beg to
differ
on the documentation front. the builtin help is ok (useful, not
stellar),
the handbook contained very little information just a few months ago
(seems they've lately started talking about doing something about it).
hg's CLI is IMO more similar to svn than that of git.
> Hg extensions must generally be written in Python, which is good or
> bad depending on your perspective.
is also possible, but you'd need to distribute binaries for windows,
and
probably would have hard time wrapping it so that it works on windows
without hassles.
> Hg's format is supposedly not as good (the Git people say
> that), but it's used on very large projects too, so I'm not sure that
> it's really all that bad. I have a large project on it at work, and it
> does fine.
hg ties them together. `hg mv x y` remembers that y used to be x,
but stores x/y's fulltext. same with `hg cp`. also, hg does not
deltify
binary files.
> AFAICT the two systems are basically equivalent in terms of
> capability. Some people may try to say otherwise, but I personally
> don't see it. An extension for one tends to show up for the other.
in the details. e. g. `hg shelve` (git stash) turned out unworthy of
my trust after a few uses several weeks ago.
> The "cool hackers" definitely use git, probably because Linus Torvalds
> wrote it. Personally, I'm not very cool, so I use Mercurial for most
> of my stuff, including at work. This is mostly because I have to use
> it on Windows sometimes, and it does very well in that situation.
now seriously: we shouldn't base the discussion on facts that are no
longer true. git is available as a native windows binary these days
(see above), and hg has only recently fixed a long-standing
windows-only repository corruption bug about which the developers
were basically in denial (hardlinks/CIFS; the standard response was
"your AV software did it").
this email isn't meant to promote git over hg. it's just that as a hg
user
i'm way more qualified to talk about its bugs than git's. and i
always
love to play a bit of a devil's advocate. ;)
--
roman
Albert Graef
> Ok, thanks. As there's been no other complaints about that, I'll go
> ahead with it.
Just a quick note to everybody with commit access (you know who you
are): I'm currently doing an svnsync to grab a local copy of the
repository, so it would probably be a good idea to not commit anything
until I'm done with that. I'll let you know when it's finished. It
shouldn't take very long, maybe half an hour or so.
Thanks,
Albert Graef
> It shouldn't take very long, maybe half an hour or so.
Well, that was too optimistic. :( After some 2 hours I've run into an
unrecoverable "Observed changes didn't match count" svnsync error, so
I'm rerunning it now. Sorry for the hassle. I hope that it succeeds this
time, otherwise I'm afraid that I'll have to start from a current
snapshot without history in hg. (The svn repo will be kept, too, so the
old history won't be lost anyway.)
Albert Graef
> Well, that was too optimistic. :( After some 2 hours I've run into an
> unrecoverable "Observed changes didn't match count" svnsync error, so
> I'm rerunning it now.
Failure again. It always bails out after r2966:
$ svnsync sync file:///home/ag/pure-lang-svn
... lots of messages ...
Transmitting file data ..
Committed revision 2966.
Copied properties for revision 2966.
svnsync: Observed changes didn't match count
Has anyone seen that error yet? Any idea how to proceed?
Anyway, I've given up for now, so please go ahead committing your stuff.
Jiri Spitz
> Failure again. It always bails out after r2966:
>
> $ svnsync sync file:///home/ag/pure-lang-svn
> ... lots of messages ...
> Transmitting file data ..
> Committed revision 2966.
> Copied properties for revision 2966.
> svnsync: Observed changes didn't match count
interrupts but it is possible to continue. I'll let you know.
Jiri
Ryan Schmidt
> Failure again. It always bails out after r2966:
>
> $ svnsync sync file:///home/ag/pure-lang-svn
> ... lots of messages ...
> Transmitting file data ..
> Committed revision 2966.
> Copied properties for revision 2966.
> svnsync: Observed changes didn't match count
>
> Has anyone seen that error yet? Any idea how to proceed?
I have been on the Subversion mailing list for years and I don't recall that message specifically. I get it too, by the way, with just a simple:
$ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk
svn: Observed changes didn't match count
$
(The -v is important; without it, it returns the log message successfully.)
The only occurrence of this problem on Google (other than yours, now) is this:
http://www.ohloh.net/forums/10/topics/4775
And they worked around it by syncing from a different mirror of the same repository.
I've asked for help with this problem on the Subversion mailing list; I'll let you know if something turns up.
Albert Graef
> I'm trying to import the tree using hgsubversion. It sometimes
> interrupts but it is possible to continue. I'll let you know.
Thanks, I hope that it goes through, that would be most helpful.
I also tried a git svn clone, but that was taking forever and was
detecting all kinds of weird branches, so I aborted it.
Ryan Schmidt
On Oct 29, 2010, at 05:40, Albert Graef wrote:
> I understand. But as you're also maintaining quite a few ports over at
> MacPorts, I guess that you'll have to come to grips with git and/or hg
> soon enough anyway. ;-) Many projects are using them now.
MacPorts generally uses stable versions of software, for which those projects generally release source tarballs and we don't have to care what VCS they're using.
In those rare cases when MacPorts actually has to connect directly to a project's VCS to download their sources, MacPorts supports cvs, svn, git, hg and bzr. Fortunately I don't have to understand how all those work; I just tell MacPorts to get the source that way and it does.
Albert Graef
> $ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk
> svn: Observed changes didn't match count
Yes, I get that, too, also for the following revisions up to 2993. Looks
there's some corruption in the repo at that point, so I'll probably have
to report an issue.
But first let's see whether Jiri has more luck with hgsubversion.
> I've asked for help with this problem on the Subversion mailing list; I'll let you know if something turns up.
Thanks,
Jiri Spitz
>
> But first let's see whether Jiri has more luck with hgsubversion.
Jiri
Ryan Schmidt
On Oct 29, 2010, at 16:27, Ryan Schmidt wrote:
> I've asked for help with this problem on the Subversion mailing list; I'll let you know if something turns up.
The response I got...
http://svn.haxx.se/users/archive-2010-10/0559.shtml
...is that this is a bug in Google's backend Subversion storage implementation. (They don't use either of the two standard well-tested Subversion backends (BDB and FSFS), but their own implementation which they feel scales better.) I think you'll have to open a support ticket with Google and hope they can uncorrupt these revisions somehow.
Chris Double
> I also tried a git svn clone, but that was taking forever and was
> detecting all kinds of weird branches, so I aborted it.
I have a git clone that I've been using for a while. The gitweb
instance is here:
http://gitweb.bluishcoder.co.nz/?p=pure.git;a=summary
You can git clone from:
git clone git://bluishcoder.co.nz/git/pure.git
You might be able to use this to popular the hg history.
Chris.
--
http://www.bluishcoder.co.nz
Albert Graef
> The response I got...
>
> http://svn.haxx.se/users/archive-2010-10/0559.shtml
>
> ...is that this is a bug in Google's backend Subversion storage implementation. (They don't use either of the two standard well-tested Subversion backends (BDB and FSFS), but their own implementation which they feel scales better.) I think you'll have to open a support ticket with Google and hope they can uncorrupt these revisions somehow.
Ryan, thanks for asking. I filed a support ticket now, you can find that
here:
http://code.google.com/p/support/issues/detail?id=4596
Let's hope that the support people at GC can fix it.
In the meantime I've installed svn 1.7.0 from the subversion repo with
the ra_serf backend, to see whether I get any further with that.
Apparently ra_serf doesn't simply bail out on the corrupt metadata, so
that might help a bit with svnsync, too.
I've also been contemplating whether we really need a full log of old
revisions, or whether it might make sense to start from a clean slate
anyway. I don't expect to have to go back to old revisions much, and if
I do, I'll still have the old svn repo for that. How do the other
developers feel about that? That would be mostly Eddie, Jiri and Peter,
as you've been the most active in recent times. Peter is in China right
now and probably doesn't have much access behind the Great Wall, but
Eddie and Jiri, I'd really appreciate your comments (Libor as well, if
you plan to contribute again in the future). Also, Sergei, would you be
fine if we only migrate a current snapshot of the wiki? I know that
you've been working quite a bit on your Pure Primer in the not so
distant past.
In any case, I want to make some minor cosmetic adjustments to get a
clean layout for the new hg repo to begin with. We only ever had one
branch which has long been merged, and the release tags are handled
differently in hg, too, so they will have to be recreated anyway (I can
hopefully do that more or less automatically with a little script). The
wiki and related stuff, if I understand correctly, will move to a
separate URL if we want to migrate it to hg.
So basically the new hg repo would be all the stuff that's under 'trunk'
right now, but at the toplevel directory of the hg repo. Does that sound
reasonable?
Albert Graef
>> But first let's see whether Jiri has more luck with hgsubversion.
> Unfortunately, I came exactly to the same result r2967 is terminal...
Jiri, thanks for trying. :)
Albert Graef
> I have a git clone that I've been using for a while. The gitweb
> instance is here:
>
> http://gitweb.bluishcoder.co.nz/?p=pure.git;a=summary
Wow, thanks! Git to the rescue. ;-) I'm cloning it now. It should be
interesting to look at the revisions which have broken metadata in svn now.
BTW, that reminds me that I wanted to add your Vorbis player to the
growing collection of Pure media packages. (Besides pd-pure and
pure-liblo, we have pure-audio, pure-midi and the ability to inline
Faust programs in Pure now.) I'll have another look at that, too.
Albert
Jiri Spitz
> I've also been contemplating whether we really need a full log of old
> revisions, or whether it might make sense to start from a clean slate
> anyway. I don't expect to have to go back to old revisions much, and if
> I do, I'll still have the old svn repo for that. How do the other
> developers feel about that? That would be mostly Eddie, Jiri and Peter,
> as you've been the most active in recent times. Peter is in China right
> now and probably doesn't have much access behind the Great Wall, but
> Eddie and Jiri, I'd really appreciate your comments (Libor as well, if
> you plan to contribute again in the future). Also, Sergei, would you be
> fine if we only migrate a current snapshot of the wiki? I know that
> you've been working quite a bit on your Pure Primer in the not so
> distant past.
history will remain accessible using svn, anyway. And migration from SF
to GC did not preserve the whole tree as well, so we have a precedent.
Jiri
Albert Graef
> Chris Double wrote:
>> I have a git clone that I've been using for a while. The gitweb
>> instance is here:
>>
>> http://gitweb.bluishcoder.co.nz/?p=pure.git;a=summary
>
> Wow, thanks! Git to the rescue. ;-) I'm cloning it now. It should be
> interesting to look at the revisions which have broken metadata in svn now.
They look fine. So after all it should be possible to reconstruct the
history for the stuff under trunk in the hg repo if we really want to.
Albert Graef
> I am fine with starting the new repo from the latest revision. The
> history will remain accessible using svn, anyway. And migration from SF
> to GC did not preserve the whole tree as well, so we have a precedent.
That's true. Also, the new repo would start out much tidier and thus
faster to clone for users. The more I think about it, the more it looks
like the right thing to do it that way. Eddie (or Libor, Peter and
Sergei, if you read this), would you have any complaints if I proceeded
that way?
Albert Graef
> In any case, I want to make some minor cosmetic adjustments to get a
> clean layout for the new hg repo to begin with. We only ever had one
> branch which has long been merged, and the release tags are handled
> differently in hg, too, so they will have to be recreated anyway (I can
> hopefully do that more or less automatically with a little script).
Brain fart on my side. If we start from a clean state then there's no
revisions for the old release tags to point to anyway. ;-) Well, we
still have all the tarballs back to version 0.1, I think that this will
do. I've been rather lazy with tagging releases in svn anyway, I promise
to do better after the move to hg...
Talking about tarballs, that reminds me that Roman has been keeping svn
snapshots on http://codex.sigpipe.cz/pure-lang/snapshots/ since August.
Roman, can you continue that with hg, too? I'd guess that the necessary
adjustments to your scripts would be minor?
Roman Neuhauser
> Albert Graef wrote:
> > Chris Double wrote:
> >> I have a git clone that I've been using for a while. The gitweb
> >> instance is here:
>
> >>http://gitweb.bluishcoder.co.nz/?p=pure.git;a=summary
>
> > Wow, thanks! Git to the rescue. ;-) I'm cloning it now. It should be
> > interesting to look at the revisions which have broken metadata in svn now.
>
> They look fine. So after all it should be possible to reconstruct the
> history for the stuff under trunk in the hg repo if we really want to.
me dig it out.
Roman Neuhauser
> Jiri Spitz wrote:
> > I am fine with starting the new repo from the latest revision. The
> > history will remain accessible using svn, anyway. And migration from SF
> > to GC did not preserve the whole tree as well, so we have a precedent.
>
> That's true. Also, the new repo would start out much tidier and thus
> faster to clone for users. The more I think about it, the more it looks
> like the right thing to do it that way. Eddie (or Libor, Peter and
> Sergei, if you read this), would you have any complaints if I proceeded
> that way?
repository structure.
Does it make sense to bundle all the modules in a single repository
with the
language itself?
Roman Neuhauser
> Talking about tarballs, that reminds me that Roman has been keeping svn
> adjustments to your scripts would be minor?
Albert Graef
> In fact, this might be a good opportunity to think about the
> repository structure.
> Does it make sense to bundle all the modules in a single repository
> with the language itself?
Good question. With svn this hasn't been a problem, since you could just
check out the parts that you needed.
We could use separate repos for all the modules, but I'd really hate to
type a gazillion of hg clone commands just to get the whole shebang.
Second, this would make it rather inconvenient to move stuff from one
subproject to another (which does happen every once in a while in
refactoring). Third, we only get a flat structure that way, when in the
future we might want something hierarchical (related modules grouped
together under one subdir).
I could maybe live with a separate repo for all the modules, but that
doesn't really offer a big advantage.
I'm going to try the all-in-one approach first. If I can manage to do
this on the abysmal connection that I have here at home, then anyone
should able to live with that. ;-)
Eddie Rucker
Eddie Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "pure-lang" group.
> To post to this group, send email to pure...@googlegroups.com.
> To unsubscribe from this group, send email to pure-lang+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pure-lang?hl=en.
>
Eddie Rucker
Eddie Sent from my iPhone
Eddie Rucker
Off topic.
If I had the money, I'ld buy an optical fiber from your provider to your house Albert. ;)
Eddie Sent from my iPhone
Albert Graef
> I say keep the modules together for convenience.
I kept the entire source (Pure core and modules) in one repo for now.
Getting a clone of the pristine source repo needed less than a minute
even on my fairly slow internet connection, and once you have a clone on
one of your computers you can easily clone it to other computers locally
which is very fast. So I think that this is acceptable.
You can have a look here:
http://code.google.com/p/pure-lang/source/browse/
Note that, as discussed earlier, this is a snapshot of the final svn
revision 3737, so it's just a single commit right now. I'll follow up
with instructions on how to use the new repo shortly.
I also migrated a snapshot of the wiki pages here:
http://code.google.com/p/pure-lang/source/browse/?repo=wiki
This doesn't show the wiki pages in the right place yet, because the GC
wiki instructions for migrating a project wiki to hg are wrong. I'm
currently correcting this, so hopefully the wiki should be back up again
in a few minutes. (I'll still have to fix up all the links to stuff in
the wiki repo, though.)
> Off topic.
> If I had the money, I'ld buy an optical fiber from your provider to your house Albert. ;)
Thanks Eddie, I really appreciate that. ;-) I still have hopes that
maybe, just maybe one day (hopefully *before* I retire) they get their
act together so that we enjoy some decent broadband connection in the
more rural areas of Germany. (I'm in the general Rhein-Main Area here,
not exactly in the highlands, but it's a little village.) They've been
planning to roll this out for quite some time now, but then the
financial crisis came along, Greece went broke, etc.
me22
>
> As far as I know, the technical advantage of Git is its filesystem
> format; people say it's faster and scales better. Some people also
> prefer the multiple small programs approach. I agree that's a nice
> thing.
>
Every technical debate I've seen about git has come down to one of two
core design decisions:
1) The repository is diff algorithm independent
2) All merge parents are equal
That leads to some fundamental consequences, which can be seen as good
or bad. For example, it means that merges don't depend on earlier
commits picking the "best" way to represent a change, but there's no
unambiguous way to say from where each line came. Also, it means that
there's no wart in the history if the (socially) root server goes down
and you use a different one temporarily, but it means that you can't
ask questions like, "from which branch did this commit come?"
I have no idea whether its trade-offs are the right choice for pure.
Roman Neuhauser
> I should have a few weeks old hg clone of the entire Pure repo. Let
> me dig it out.
http://pure-lang.googlecode.com/svn i've been using as incoming
for my hacks. the tip is svn rev 3737, "Don't build the realtime
module on Windows for now.". there's 2761 revisions in the
mercurial repository because it doesn't contain revisions modifying
the wiki for some reason.
--
roman
Roman Neuhauser
> On 30 říj, 09:36, Roman Neuhauser <roman.neuhau...@ge.com> wrote:
>
> > I should have a few weeks old hg clone of the entire Pure repo. Let
> > me dig it out.
>
> module on Windows for now.". there's 2761 revisions in the
> mercurial repository because it doesn't contain revisions modifying
> the wiki for some reason.
Albert Graef
> i guess i'm too late but for completeness: i've dug out the clone of
> http://pure-lang.googlecode.com/svn i've been using as incoming
> for my hacks. the tip is svn rev 3737, "Don't build the realtime
> module on Windows for now.".
Yup, that's the final svn revision, thanks a bunch! I'm cloning it now.
It might be a good idea to put it on GC, say, as a separate
'pure-lang-old' repo, so that we can get easier access to the old stuff
via GC's web interface again.
Thanks,
Albert
Roman Neuhauser
> Roman Neuhauser wrote:
> > i guess i'm too late but for completeness: i've dug out the clone of
> > module on Windows for now.".
>
> Yup, that's the final svn revision, thanks a bunch! I'm cloning it now.
> It might be a good idea to put it on GC, say, as a separate
> 'pure-lang-old' repo, so that we can get easier access to the old stuff
> via GC's web interface again.
as reported by du -hs on this particular filesystem. if i were in
your position i wouldn't reset the repository if it were possible to
keep the history. it's not like the history is needed frequently, but
when it is, having it in the repository as opposed to some "offline"
source is golden. but that's just me: i'm a lazy packrat.
Albert Graef
> It might be a good idea to put it on GC, say, as a separate
> 'pure-lang-old' repo, so that we can get easier access to the old stuff
> via GC's web interface again.
Done. You can now browse the old stuff here:
http://code.google.com/p/pure-lang/source/browse/?repo=old
If you want a local copy:
hg clone https://old.pure-lang.googlecode.com/hg/ pure-lang-old
This should be considered read-only. (Of course you can do with your
local copies what you want, but please don't push any changes.)
Albert Graef
> the old repository is only twice as big as the new one, 9.5M vs 4.1M
> as reported by du -hs on this particular filesystem. if i were in
> your position i wouldn't reset the repository if it were possible to
> keep the history.
Well, O(2) = O(1) in theory, but not in practice, especially on a slow
internet connection. Of course the ratio will go down with time. I'd
like to wait and see whether this really becomes an issue. I don't
usually have to back out really old changes. I do look up old changes
every once in a while to find out why and in which context I made a
certain change, but browsing the 'old' repo makes that possible now.
Also, the old history is pretty dirty in some places. Stuff I forgot to
commit, botched commits, the usual stuff. With hg and histedit this
won't happen nearly as often now, I hope.
Of course, if any of the other contributors thinks that we should keep
the history after all, I'll do it. But so far everyone involved seems to
be happy with starting from a clean slate.
Albert Graef
> the old repository is only twice as big as the new one, 9.5M vs 4.1M
> as reported by du -hs on this particular filesystem.
Hmm, I get totally different figures. 20M for the new one vs. 25M for
the old one (with the latest revisions already applied). Any reason why
my figures are so much different from yours? Do you use some kind of
compression?
Anyway, with these figures the cost for including the old history
doesn't look nearly as bad. So I might as well do it. Of course, I'll
have to reinit the central repo, so anyone who has cloned it already
will have to redo that. Everyone fine with that?
Albert Graef
> Roman Neuhauser wrote:
>> the old repository is only twice as big as the new one, 9.5M vs 4.1M
>> as reported by du -hs on this particular filesystem.
Maybe you du'ed just the metadata in .hg? I get similar figures there
(5.6M vs. 12M).
> Anyway, with these figures the cost for including the old history
> doesn't look nearly as bad. So I might as well do it. Of course, I'll
> have to reinit the central repo, so anyone who has cloned it already
> will have to redo that. Everyone fine with that?
Well, noone complained, so I actually did that now. (Ryan, sorry if your
repo checkout just became a little slower still, I hope that it's not a
big problem.) So the default repo now has all history from the svn repo,
except for the old release tags (I can add these if there's enough
demand). Scott's old matrix_opt branch is still there, but I've closed
it now since it's been merged back into the trunk ages ago already.
IMPORTANT: If you already cloned the repo, you'll have to do so again:
hg clone https://pure-lang.googlecode.com/hg/ pure-lang
Please don't try to push from old checkouts to the GC repo. If you
already have some pending changesets, you can export them from your old
clone (hg export) and reapply them on top of the new clone (hg import),
then push from the new clone.
Ok, I'm glad that we could restore the history after all. Thanks Roman!
Neuhauser, Roman (GE Capital, consultant)
> Roman Neuhauser wrote:
> > the old repository is only twice as big as the new one, 9.5M vs 4.1M
> > as reported by du -hs on this particular filesystem.
>
> Hmm, I get totally different figures. 20M for the new one vs. 25M for
> the old one (with the latest revisions already applied). Any reason why
> my figures are so much different from yours? Do you use some kind of
> compression?
because i was measuring bare repository sizes, as in, just the .hg dirs?
working directory size is orthogonal to network transfer size, which was
your concern.
btw, i get 3M for the repository, and 15M for the whole shebang (the
no-history version) including the working dir on one windows box.
du numbers depend on the filesystem parameters, i don't know what
Unreal Commander on the windows machine reports.
--
roman
Albert Graef
> because i was measuring bare repository sizes, as in, just the .hg dirs?
> working directory size is orthogonal to network transfer size, which was
> your concern.
Right, I understand that now. :) Thanks for the explanation.
Roman Neuhauser
> Ok, I'm glad that we could restore the history after all. Thanks Roman!
have returned several weeks ago as i got a new one.
glad i was sitting on it for so long. ;)
--
roman
Roman Neuhauser
there was however a glitch that caused failures in `make dist` (in
pure/). see the 5.5KB logs from 02-Nov-2010 to 04-Nov-2010 at
http://codex.sigpipe.cz/pure-lang/snapshots/logs/pure/. i've finally
got around the problem with a fresh clone today, but that's just a
workaround, and the dysfunction could return. i'll have a closer look
over the weekend, hopefully.
--
roman
Albert Graef
> the changes were indeed minor and i rolled them out two days ago.
> there was however a glitch that caused failures in `make dist` (in
> pure/). see the 5.5KB logs from 02-Nov-2010 to 04-Nov-2010 at
> http://codex.sigpipe.cz/pure-lang/snapshots/logs/pure/. i've finally
> got around the problem with a fresh clone today, but that's just a
> workaround, and the dysfunction could return. i'll have a closer look
> over the weekend, hopefully.
I've regenerated purelib.txt and the html docs in pure-lang/pure now, so
at least the issue visible in the 04-Nov-2010 logs should be fixed for
now. But while I continue migration to Spinx, intermittent problems with
docs being out of sync are not completely unlikely. ;-)
(Note to self: when we move the html docs out of the source tree,
purelib.txt must bite the dust as well. This was only added to make
'make html' work even without having pure-doc installed.)
Roman Neuhauser
> Roman Neuhauser wrote:
> > the changes were indeed minor and i rolled them out two days ago.
> > there was however a glitch that caused failures in `make dist` (in
> > pure/). see the 5.5KB logs from 02-Nov-2010 to 04-Nov-2010 at
> >http://codex.sigpipe.cz/pure-lang/snapshots/logs/pure/. i've finally
> > got around the problem with a fresh clone today, but that's just a
> > workaround, and the dysfunction could return. i'll have a closer look
> > over the weekend, hopefully.
>
> I've regenerated purelib.txt and the html docs in pure-lang/pure now, so
> at least the issue visible in the 04-Nov-2010 logs should be fixed for
> now. But while I continue migration to Spinx, intermittent problems with
> docs being out of sync are not completely unlikely. ;-)
/usr/local/bin/gmake dist version=201011061800
/usr/local/bin/flex -o ./lexer.cc lexer.ll
bison -v -o ./parser.cc parser.yy
./run-test -n lib/prelude.pure > test/prelude.log 2>&1
gmake: *** [test/prelude.log] Error 127
Albert Graef
> is this something for you?
>
> /usr/local/bin/gmake dist version=201011061800
> /usr/local/bin/flex -o ./lexer.cc lexer.ll
> bison -v -o ./parser.cc parser.yy
> ./run-test -n lib/prelude.pure > test/prelude.log 2>&1
> gmake: *** [test/prelude.log] Error 127
This looks like another case of generated files in the repo looking old
when in reality they aren't. In this case it's test/prelude.log which is
in the prerequisites of the 'dist' target and depends on a number of
standard library scripts, including lib/prelude.pure itself. So it tries
to regenerate the log there because its prerequisites look younger, and
of course this doesn't work if you haven't build the interpreter yet.
(This can easily happen if some of the prelude modules got updated
without rendering prelude.log invalid. Which is in fact the normal case
since it means that the prelude check still passes.)
Oh well. The golden logs really need to be in the repo, otherwise there
would be no way to test a fresh checkout of the interpreter.
I think that the proper solution is to just remove the *.log files from
the prerequisites of the 'dist' target, even though 'dist' depends on
them. The logs are not something that gets rebuilt in normal operation,
so we can just take for granted that they are there.
Do you agree? The only other solution I see would involve fiddling with
timestamp files, but this seems overkill to me.
Roman Neuhauser
> I think that the proper solution is to just remove the *.log files from
> the prerequisites of the 'dist' target, even though 'dist' depends on
> them. The logs are not something that gets rebuilt in normal operation,
> so we can just take for granted that they are there.
>
> Do you agree? The only other solution I see would involve fiddling with
> timestamp files, but this seems overkill to me.
current state, at least as a temporary measure. i say go for it.
--
roman
Albert Graef
> removing the log files from dist prerequisities is better than the
> current state, at least as a temporary measure. i say go for it.
Done. Please let me know if you still have any problems building the hg
snapshots.
Roman Neuhauser
> Roman Neuhauser wrote:
> > removing the log files from dist prerequisities is better than the
> > current state, at least as a temporary measure. i say go for it.
>
> Done. Please let me know if you still have any problems building the hg
> snapshots.
--
roman