User forums > Help
error when compiling from svn sources (25-10/2006)
thomas:
--- Quote from: afb on October 30, 2006, 01:29:10 pm ---
--- Quote from: killerbot on October 30, 2006, 01:22:33 pm ---my svn is 1.3.0, but I get errors instead of warnings.
--- End quote ---
I thought svn 1.4.0 was required now ?
--- End quote ---
All that matters is what a man can do, and what a man can't do.
For instance, you can:
- check out with Subversion 1.4 and have svn in PATH
- check out with Subversion 1.4 and not have svn available
- check out with Subversion 1.0, 1.1, 1.2, or 1.3 and have svn in PATH
What you cannot do is:
- check out using 1.3 and not have svn in PATH
- check out using 1.4 and have svn 1.3 in PATH
- check out using 1.3, update using 1.4, then change your mind and expect things still to work
Are you man enough to sail under a pirate's flag then? 8)
afb:
--- Quote from: thomas on October 30, 2006, 01:51:46 pm ---Are you man enough to sail under a pirate's flag then? 8)
--- End quote ---
I use CVS :-P
But I guess checking out with /opt/local/bin/svn was a bad idea.
When I have to compile SVN, then I might as well go for 1.4.0...
ddd:
--- Quote from: thomas on October 30, 2006, 01:46:03 pm ---Interesting... I even considered using LANG=jwsdhadgh or LANG=none for a while, since gettext should fall back to whatever is built-in if it can't find it (which is the desired effect). :lol:
But then, LANG=EN looked a lot nicer, so I stuck with that. Interestingly, it does not produce any kind of warning under Windows :(
I did not choose any kind of subset such as en_US because I wasn't sure which one to take (US citizens will probably claim that en_US is without doubt the "original thing", but UK residents will not necessarily agree that this is English at all). I don't know which one is the native one. Maybe en_US and en_UK (or en_AU) are even the same for Subversion by coincidence. But honestly, I actually don't want to bother ;)
What we need is one format that's always the same, preferrably the one that's built into the Subversion binary, so it will run on every target PC. My proposal is that you try whatever doesn't give you errors, and we'll stick with that for now (until someone else complains).
--- End quote ---
Isn't it possible to unset the variable instead? Wouldn't that produce the output that is built inside svn?
I tried both unsetting the variable and setting it to empty, and I got english text output. (I'm using Ubuntu Linux)
Game_Ender:
--- Quote from: thomas on October 30, 2006, 01:46:03 pm ---Eventually, at some point in the future, I will rewrite autorevision to parse Subversion's xml output, which will once and for all end this sad story.
However, since most people still use 1.3 (which only supports that option for a small subset of commands) and some even 1.2 (which doesn't support it at all), this is currently probably not such a good idea.
--- End quote ---
The subversion developers don't recommend parsing the output of the subversion command lines tools. That's why your job is so hard. Have you considered using the libraries they provide instead?
thomas:
--- Quote from: Game_Ender on October 31, 2006, 12:52:51 am ---The subversion developers don't recommend parsing the output of the subversion command lines tools. That's why your job is so hard. Have you considered using the libraries they provide instead?
--- End quote ---
Alas, poor Yorick! I knew him, Horatio: a fellow of infinite jest, of most excellent fancy...
That question should get you the best-computer-joke-of-the-year award :)
As this is the first obvious thing to try for a Subversion plugin (rather than launch an external tool that is not found / the wrong version / slow / error-prone), I certainly tried before.
The libraries they provide neither work with MinGW, nor does it seem feasible to convert them. Compiling Subversion from source is a story of its own...
The first dependency is Neon. Get back to me when you have managed to compile Neon with MinGW :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version