Re: svn and object oriented programming in MATLAB
On May 19, 2011, at 17:16, Kerri Stone wrote: > When using OO in MATLAB, directories (or classes) are prefixed with an '@'. > Subversion, however, uses the @ for peg revisions. Due to subversion > thinking the @ delineates a peg revision, it is impossible to name a > directory '@className' and check that directory into svn. Is there a way to > work around peg revisions in svn to version control MATLAB projects that > contain classes? The standard workaround is to specify the peg revision anyway, even if you wouldn't otherwise need it (i.e. append "@HEAD"). If that doesn't work, please show the commands you're running and their output.
Is the peg revision syntax a bug?
Hi!
I've seen quite a few people confused by peg revisions including myself, last
case being the thread about "object oriented programming in MATLAB". Thinking
about that, I'm more and more willing to consider the way peg revisions are
taken from the commandline as a bug. The main reason is simply that it is
surprising, which regular questions show.
I basically wanted to ask if there already is a bug ticket and if there even
is consensus on how to treat it. I found ticket 2317, but I couldn't locate
the according revision when this was fixed or how - the second part of the
suggestion seems to not have been implemented.
Just for the record, my opinion is that the peg revision should not be part of
the URL. At least it shouldn't be part of the URL's end, I'd rather add it to
the beginning (specifying the root revision for the file tree) or maybe use
the same way that POST parameters are encoded for HTTP ("/foo/bar?x=y&a=b").
However, I would prefer to have it as separate and explicit argument on the
commandline, just as the "normal" revision is also passed with [-r|--revision]
there. This makes it easier to understand and parse, and it avoids confusion
because it is explicit and not mixed in the URL. I would then deprecate and
warn about the peg revision in the URL for 2..3 years and then remove this
syntax.
Thoughts?
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: Generating SVN libraries from source on Mac OSX
Oops. Thank-you for pointing that out, my mistake. However, I still cannot find any libsvn*.a files anywhere on the drive. As described in my first mail, there is a file I can see with the extension 'LA' which is a text file. It states that the libraries will be built to /usr/local/lib but they don't seem to be there after I execute make. ./configure --disable-shared --enable-static make Thanks, Ian. On 19 May 2011, at 17:31, Blair Zajac wrote: > Static libraries end in .a, not .dylib, those are shared. > > Blair > > On May 19, 2011, at 9:23 AM, Ian Sidor wrote: > >> I tried --disable-shared but I still didn't get any libsvn*.dylib files. >> >> Is there anything else I can try? >> >> >> On 19 May 2011, at 07:47, Daniel Shahaf wrote: >> >>> Just ignore the file you don't need then? >>> >>> Or try --disable-shared >>> >>> Ian Sidor wrote on Thu, May 19, 2011 at 00:00:45 +0100: I'm building Subversion from source in order to generate static libraries to use in my own application. I can build Subversion fine but I don't seem to be getting any libraries (dylib's). Here is what I type in terminal: curl -O http://subversion.tigris.org/downloads/subversion-1.6.16.tar.gz curl -O http://subversion.tigris.org/downloads/subversion-deps-1.6.16.tar.gz tar xzvf subversion-1.6.16.tar.gz tar xzvf subversion-deps-1.6.16.tar.gz ./configure --enable-static make I found a file 'libsvn_client-1.la' which is required for linking. The text inside describes 'libsvn_client-1.dylib' but it is never generated after make is executed. I've tried everything I can think of & no doubt missing something simple, I'm not too familiar with Unix open source conventions. Can someone help me with this please? Thank-you. Ian. >> >
Re: Is the peg revision syntax a bug?
On Fri, May 20, 2011 at 11:14:45AM +0200, Ulrich Eckhardt wrote:
> Hi!
>
> I've seen quite a few people confused by peg revisions including myself, last
> case being the thread about "object oriented programming in MATLAB". Thinking
> about that, I'm more and more willing to consider the way peg revisions are
> taken from the commandline as a bug. The main reason is simply that it is
> surprising, which regular questions show.
It is documented in the book so I don't see how it can be surprising.
It can be awkward, unusual, or simply off-putting depending on personal
taste. But why surprising?
> I basically wanted to ask if there already is a bug ticket and if there even
> is consensus on how to treat it. I found ticket 2317, but I couldn't locate
> the according revision when this was fixed or how - the second part of the
> suggestion seems to not have been implemented.
The current consensus is the current syntax.
It can be escaped by appending an @ character at the end of the path
argument.
We've had bugs in some subcommands where the trailing @ was ignored:
http://subversion.tigris.org/issues/show_bug.cgi?id=3416
http://subversion.tigris.org/issues/show_bug.cgi?id=3651
Such bugs have caused confusion in the past since the behaviour
of several subcommands was inconsistent. But these should be fixed now.
If you find any additional bugs in peg revision handling, please let us
know :)
> Just for the record, my opinion is that the peg revision should not be part
> of
> the URL. At least it shouldn't be part of the URL's end, I'd rather add it to
> the beginning (specifying the root revision for the file tree) or maybe use
> the same way that POST parameters are encoded for HTTP ("/foo/bar?x=y&a=b").
That would not be as easy to type as the current syntax.
> However, I would prefer to have it as separate and explicit argument on the
> commandline, just as the "normal" revision is also passed with
> [-r|--revision]
What if you need to pass more than one peg revision argument?
E.g. for a merge I might need to pass URL1@REV1 and URL2@REV2.
What would the options be in this case?
Keep in mind that svn doesn't care where option names appear on the
command line. They can appear in any order and at any place.
> there. This makes it easier to understand and parse, and it avoids confusion
> because it is explicit and not mixed in the URL. I would then deprecate and
> warn about the peg revision in the URL for 2..3 years and then remove this
> syntax.
>
As per our compatibility guidelines we cannot remove this syntax at all
before Subversion 2.0. We can deprecate it but we need to keep supporting it.
Re: Generating SVN libraries from source on Mac OSX
On May 20, 2011, at 05:40, Ian Sidor wrote: > However, I still cannot find any libsvn*.a files anywhere on the drive. All I know is Subversion correctly builds both static and dynamic libraries when installed with MacPorts. $ port installed subversion The following ports are currently installed: subversion @1.6.16_0+mod_dav_svn+tools+universal (active) $ port contents subversion | grep \\.a$ /opt/local/lib/libsvn_client-1.a /opt/local/lib/libsvn_delta-1.a /opt/local/lib/libsvn_diff-1.a /opt/local/lib/libsvn_fs-1.a /opt/local/lib/libsvn_fs_base-1.a /opt/local/lib/libsvn_fs_fs-1.a /opt/local/lib/libsvn_fs_util-1.a /opt/local/lib/libsvn_ra-1.a /opt/local/lib/libsvn_ra_local-1.a /opt/local/lib/libsvn_ra_neon-1.a /opt/local/lib/libsvn_ra_serf-1.a /opt/local/lib/libsvn_ra_svn-1.a /opt/local/lib/libsvn_repos-1.a /opt/local/lib/libsvn_subr-1.a /opt/local/lib/libsvn_wc-1.a You could read the MacPorts subversion Portfile, and install subversion with MacPorts and read the debug output, to see exactly how that's accomplished; maybe you can adapt that for your own manual build. Or maybe you can just make use of the libraries MacPorts installs, and forgo building manually.
Re: Generating SVN libraries from source on Mac OSX
On May 20, 2011, at 3:40 AM, Ian Sidor wrote: > Oops. Thank-you for pointing that out, my mistake. > > However, I still cannot find any libsvn*.a files anywhere on the drive. > > As described in my first mail, there is a file I can see with the extension > 'LA' which is a text file. It states that the libraries will be built to > /usr/local/lib but they don't seem to be there after I execute make. You have to run make install to get them to install into /usr/local/lib. BTW, if you're building libraries for your application, it's probably best to pick a different directory than /usr/local, since it's a common dumping ground. Choose something like /opt/my_company_name/product_name. Also, you could build with MacPorts into /opt/my_company_name/product_name and then have it provide all the .a's. Blair
