You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dominik Westner <li...@logicunited.com> on 2001/09/02 15:52:26 UTC
Successful bootstrap on Mac OS X
Hi,
I am not sure if this is the correct mailing list, but I just wanted to
tell you, that I was able to compile subversion-M3 on Mac OS X 10.04.
I then checked out subversion from the repository and compiled it again.
It also ran all tests successfully and I was able to upgrade to version
22
I had the following problems when compiling:
--with-berkeley-db=/usr/local/BerkeleyDB.3.3 does not seem to work, I
had to create a link from the db sources to db
Mac OS X uses a case insensitiv file system, when it tries to link the
svn program it will the linker will throw an error that the file is
already existing as a directory. The SVN directory is in the way. I
tried to use the --program-suffix=SUFFIX option, but the option seems
to be ignored.
Workaround: move the SVN directory out of the way.
Wouldn't it be better in general to use .svn or .SVN instead of SVN?
One final question come into my mind about the features of subversion:
is it possible to marks a directory as binary? This would imply that the
directory and all its contents would get managed as a single entity.
Ok, finally thanks for making this available. It looks like this is
going to be a honorable successor of CVS ;-)
I am happy to help if there is any work for a spoiled Java/Objective-
C/Ruby programmer ;-)
Greetings
Dominik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'SVN' to '.svn'
Posted by Brian Behlendorf <br...@collab.net>.
On 4 Sep 2001, Ben Collins-Sussman wrote:
> We've had this discussion before, and I believe the consensus was that
> the name of the administrative directory would be a run-time switch
> read out of a user's .svnrc. The .svnrc would give 2 or 3 choices:
> "SVN", ".SVN", ".svn", or something like that.
So long as it could be overridden by a .snvrc in the current dir - I'm
thinking of the case where people would distribute tarballs which are
essentially a local working copy so that one could simply do a "svn
update" after untarring the tarball to pull down the latest code, rather
than a checkout from scratch which would (probably) take much longer.
This is done now with CVS and various projects, apache, openoffice, etc.
Obviously, the tarball preparer will choose an admin dir name, and somehow
the client should pick up on that reliably.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on
Mac OS X
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On 4 Sep 2001, Ben Collins-Sussman wrote:
> We've had this discussion before, and I believe the consensus was that
> the name of the administrative directory would be a run-time switch
> read out of a user's .svnrc. The .svnrc would give 2 or 3 choices:
> "SVN", ".SVN", ".svn", or something like that.
OK, the other problem with that is that (currently with CVS) people like
creating tar-balls with the CVS directories included. This saves much of
the cost of the first 'cvs update' or 'cvs checkout' and is very much
appreciated for large heavily-accessed CVS trees (the linux kernel CVS at
rutgers, or the m68k port, for example). This is going to be a
*nightmare* (sure to be widely misconstrued as a bug) if the person
creating the tarball uses a different .svnrc setting than the person
unpacking it.
I would strongly recommend a *per-directory* flag (which applies to
subdirectories). This is similar to .cvsignore except for the directory
recursion. That way, project maintainer X, who likes '..XXsvnXX..' (say)
can simply make sure that there is a '.svnrc' file at top-level of his
project which sets this preference. Than all the tar-ball unpackers will
end up with ..XXsvnXX.. directories too and everything will work.
THIS IS NOT A TRIVIAL MATTER. Subversion itself is an example where an
improperly chosen 'SVN/.svn/.SVN' setting could cause the build to fail
(using 'SVN' directories names while trying to create the 'svn' binary on
a case-insensitive filesystem). It is *vital* that the project be able to
specify its own directory-name preferences.
--s
[I personally think y'all should chose a name and stick with it, but if
you *do* allow user prefs, than the above mechanism is a requirement.]
genetic hack Peking AES plutonium for Dummies Noriega Indonesia domestic disruption
assassinate COBRA JANE NORAD interception security Rijndael RUCKUS
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> I've been casually nudging (off-list) for `.svn' for about 6 months
> now. You'd have NO problem getting my +1 on this one.
The problem here is not the idea of using ".svn" or ".SVN", but rather
to the idea of *forcing* this to be the only choice.
Really, a lot of people *like* having visible administrative
directories; it's not just a lazy holdover from CVS. For example, I
know that Karl and I *want* to enter a directory and instantly be
reminded that it's under revision control. We don't want to have to
remember to 'ls -l' to find out.
Still, we understand the other use case -- hiding the directory is
especially useful on case-insensitive systems.
We've had this discussion before, and I believe the consensus was that
the name of the administrative directory would be a run-time switch
read out of a user's .svnrc. The .svnrc would give 2 or 3 choices:
"SVN", ".SVN", ".svn", or something like that.
So, (Branko), if config-file-parsing is working, perhaps somebody can
modify client/cmdline/main.c to start parsing an .svnrc file. Then in
svn_wc.h, we can define SVN_WC_ADM_DIR_NAME at runtime.
Of course, there's a "wrench" in this idea. Look at Karl's comment in
svn_wc.h:
/*** Administrative subdir. ***/
/* Ideally, this would be completely private to wc internals (in fact,
it used to be that adm_files.c:adm_subdir() was the only function
who knew the adm subdir's name). However, import wants to protect
against importing administrative subdirs, so now the name is a
matter of public record.
### kff:
Note that the import issue throws a wrench in our tentative plans
to give client users optional control over the adm subdir name.
Sure, I can tell my client to override this constant, but all the
other people in the world importing trees don't know about my
choice. What happens when I try to check out their tree? Perhaps
a centralized decision is called for after all. */
#define SVN_WC_ADM_DIR_NAME "SVN"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by cm...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> Let's wait and hear from Mike and Ben (Karl doesn't get to vote since he
> isn't here... hehe), but the tide *does* seem to suggest renaming the
> bugger.
I've been casually nudging (off-list) for `.svn' for about 6 months
now. You'd have NO problem getting my +1 on this one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 03, 2001 at 05:49:38PM +0200, Dominik Westner wrote:
>...
> Actually I got it to work with v22 from the repository. So it was
> either the M3 or I had something bad in the config.cache.
We *do* cache the results of our search for the DB stuff. I'm not sure if
that is the best thing to do, but configure *does* cache the state of other
libraries and headers it searches for (i.e. you'd probably have the same
problem locating stdio.h if it didn't exist in the first run).
> > > I like .svn. The only reason we have SVN for the name is a legacy
> > > similarity to CVS. I can't really think of a reason to keep them
> > > "visible".
> >
> > I personally don't think we need to stay in the CVS mindset. If it would
> > count I would vote +1 for moving from "SVN" to ".svn". It is only 1 #define
> > :)
> > And possibly a quick directory rename script for the developers.
>
> My vote is for .svn instead of SVN, too.
Let's wait and hear from Mike and Ben (Karl doesn't get to vote since he
isn't here... hehe), but the tide *does* seem to suggest renaming the
bugger.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by Dominik Westner <li...@logicunited.com>.
On Montag, September 3, 2001, at 04:10 Uhr, Sander Striker wrote
...
>>
>>> I had the following problems when compiling:
>>>
>>> --with-berkeley-db=/usr/local/BerkeleyDB.3.3 does not seem to work, I
>>> had to create a link from the db sources to db
>>
>> Hmm. Can you locate the relevant section of your config.log and post
>> that?
>> Or better yet: figure out why it didn't like that path?
>
> I had the same problem. Haven't figured out what it is yet. The
> configure
> script claims to be looking in '/opt/db' for 3.3.11, but isn't finding
> it,
> although it is installed there. FYI, this is with the M3 tarball on a
> linux 2.4.3 system. I haven't tried the checked out copy with an
> external
> db path yet.
Actually I got it to work with v22 from the repository. So it was either
the M3 or I had something bad in the config.cache.
>
...
>>> tried to use the --program-suffix=SUFFIX option, but the option seems
>>> to be ignored.
>>
>> Yup. I took it a look. It is ignored... Can you provide a patch? I'd
>> think
>> you would want to AC_SUBST(program_suffix) into the Makefile, then
>> tweak
>> gen-make.py to append $(program_suffix) on the end of executable
>> names when it generates a LINK line.
>>
>>> Workaround: move the SVN directory out of the way.
>>>
>>> Wouldn't it be better in general to use .svn or .SVN instead of SVN?
>>
>> I like .svn. The only reason we have SVN for the name is a legacy
>> similarity to CVS. I can't really think of a reason to keep them
> "visible".
>
> I personally don't think we need to stay in the CVS mindset. If it
> would
> count I would vote +1 for moving from "SVN" to ".svn". It is only 1
> #define
> :)
> And possibly a quick directory rename script for the developers.
>
My vote is for .svn instead of SVN, too.
Dominik
Logic United GmbH
Tel: 089-12162597
PGP Key:
mailto:westner@logicunited.com?Subject=GET%20public%20pgp%20key
Re: 'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by Daniel Stenberg <da...@haxx.se>.
On Mon, 3 Sep 2001, Sander Striker wrote:
> I personally don't think we need to stay in the CVS mindset. If it would
> count I would vote +1 for moving from "SVN" to ".svn". It is only 1
> #define :)
For what its worth, I too am +1 on this. It'll make things nicer, IMHO.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
'SVN' to '.svn' WAS: RE: Successful bootstrap on Mac OS X
Posted by Sander Striker <st...@apache.org>.
Hi,
> Greg Stein wrote:
>> On Sun, Sep 02, 2001 at 05:52:26PM +0200, Dominik Westner wrote:
>> Hi,
>>
>> I am not sure if this is the correct mailing list, but I just wanted to
>> tell you, that I was able to compile subversion-M3 on Mac OS X 10.04.
>> I then checked out subversion from the repository and compiled it again.
>> It also ran all tests successfully and I was able to upgrade to version
>> 22
>
> Cool :-)
>
> [ and yes, it is the correct list ]
>
>> I had the following problems when compiling:
>>
>> --with-berkeley-db=/usr/local/BerkeleyDB.3.3 does not seem to work, I
>> had to create a link from the db sources to db
>
> Hmm. Can you locate the relevant section of your config.log and post that?
> Or better yet: figure out why it didn't like that path?
I had the same problem. Haven't figured out what it is yet. The configure
script claims to be looking in '/opt/db' for 3.3.11, but isn't finding it,
although it is installed there. FYI, this is with the M3 tarball on a
linux 2.4.3 system. I haven't tried the checked out copy with an external
db path yet.
> > Mac OS X uses a case insensitiv file system, when it tries to link the
> > svn program it will the linker will throw an error that the file is
> > already existing as a directory. The SVN directory is in the way. I
>
> Urf. Never thought of that one :-)
*grin* Case sensitivity is something that people running *nix most of
the time tend to forget.
> > tried to use the --program-suffix=SUFFIX option, but the option seems
> > to be ignored.
>
> Yup. I took it a look. It is ignored... Can you provide a patch? I'd think
> you would want to AC_SUBST(program_suffix) into the Makefile, then tweak
> gen-make.py to append $(program_suffix) on the end of executable
> names when it generates a LINK line.
>
> > Workaround: move the SVN directory out of the way.
> >
> > Wouldn't it be better in general to use .svn or .SVN instead of SVN?
>
> I like .svn. The only reason we have SVN for the name is a legacy
> similarity to CVS. I can't really think of a reason to keep them
"visible".
I personally don't think we need to stay in the CVS mindset. If it would
count I would vote +1 for moving from "SVN" to ".svn". It is only 1 #define
:)
And possibly a quick directory rename script for the developers.
[...]
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: Successful bootstrap on Mac OS X
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On Sun, 2 Sep 2001, Greg Stein wrote:
> > Workaround: move the SVN directory out of the way.
> >
> > Wouldn't it be better in general to use .svn or .SVN instead of SVN?
>
> I like .svn. The only reason we have SVN for the name is a legacy similarity
> to CVS. I can't really think of a reason to keep them "visible".
I dislike invisible files as a rule, although CVS has .cvsignore and I
guess that hasn't bothered me too much. I wonder about renaming the
directories just to avoid a conflict with the SVN binary. It seems that
building the binary as 'svn-preinstall' or something would be a much
better choice. (This isn't $(programsuffix); it's just a preinstall name.)
--s
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Successful bootstrap on Mac OS X
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Sep 02, 2001 at 05:52:26PM +0200, Dominik Westner wrote:
> Hi,
>
> I am not sure if this is the correct mailing list, but I just wanted to
> tell you, that I was able to compile subversion-M3 on Mac OS X 10.04.
> I then checked out subversion from the repository and compiled it again.
> It also ran all tests successfully and I was able to upgrade to version
> 22
Cool :-)
[ and yes, it is the correct list ]
> I had the following problems when compiling:
>
> --with-berkeley-db=/usr/local/BerkeleyDB.3.3 does not seem to work, I
> had to create a link from the db sources to db
Hmm. Can you locate the relevant section of your config.log and post that?
Or better yet: figure out why it didn't like that path?
> Mac OS X uses a case insensitiv file system, when it tries to link the
> svn program it will the linker will throw an error that the file is
> already existing as a directory. The SVN directory is in the way. I
Urf. Never thought of that one :-)
> tried to use the --program-suffix=SUFFIX option, but the option seems
> to be ignored.
Yup. I took it a look. It is ignored... Can you provide a patch? I'd think
you would want to AC_SUBST(program_suffix) into the Makefile, then tweak
gen-make.py to append $(program_suffix) on the end of executable names when
it generates a LINK line.
> Workaround: move the SVN directory out of the way.
>
> Wouldn't it be better in general to use .svn or .SVN instead of SVN?
I like .svn. The only reason we have SVN for the name is a legacy similarity
to CVS. I can't really think of a reason to keep them "visible".
> One final question come into my mind about the features of subversion:
> is it possible to marks a directory as binary? This would imply that the
> directory and all its contents would get managed as a single entity.
What do you mean by "managed"? That is the tricky part. We can definitely
mark a directory as binary, but the semantics of that are unclear from your
post. I know you're referring to bundles (or whatever they're called now),
but I'm not sure how you would think they should be handled by SVN.
> Ok, finally thanks for making this available. It looks like this is
> going to be a honorable successor of CVS ;-)
>
> I am happy to help if there is any work for a spoiled Java/Objective-
> C/Ruby programmer ;-)
Actually: we intend to create Java and Ruby bindings via SWIG. (we're also
doing a hand-written Java binding) If you're at all familiar with SWIG,
then it would be great for you to assist with the SWIG/Ruby bindings. ??
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org