Re: svn delete removes read-only files

[David Chapman]

On 11/19/2013 6:28 PM, Ryan Schmidt wrote:

On Nov 18, 2013, at 10:37, Rick Varney wrote:


So for Redhat 5, rm does seem to give read-only files some special
treatment.  The fact that rm on your OS does not makes me wonder if I am
wrong about how typical this behavior is in other Linux/Unix flavors.

Both GNU rm (used on Linux) and BSD rm (used on OS X and *BSD) do this. From 
the BSD rm manpage on OS X 10.9:


It's quite possible that I haven't read the rm man page since the 
1980s.  :-)  Also, the only time I tend to have read-only files is when 
I am running as superuser, in which case I run "rm -f" to get rid of 
stuff without the prompt from the "rm -i" alias that is the default 
within the superuser account.  So I have never seen the prompt.


For the record, my machines mostly run CentOS, so they have the behavior 
described.  I just confirmed this by creating a read-only file in a 
non-superuser account.  Guess I learned something today.


--
David Chapman  dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

Re: Empty rpath when attempting make swig-py

[Ben Reser]

On 11/16/13 8:53 PM, jason mazzotta wrote:
> Hi,
> I am trying to build the swig python bindings for subversion on Mac OS X.
>  I downloaded source for subversion from here:
> 
> http://opensource.apple.com/release/os-x-109/

I don't see Subversion listed on that site.  However my guess would be that's a
really old version since Apple as far as I know is still shipping 1.7.x (or
1.6.x if you're on an older version of OS X).

So I'd suggest you get a copy of the source from the project site here:
http://subversion.apache.org/download/

Alternatively you could just get a binary package.  I know for instance that
the WANdisco binaries include bindings:
http://subversion.apache.org/packages.html

If you still want to build anyway.  Note that in order for SWIG bindings to
build properly on OS X you'll need to regenerate the swig interface source
files.  We include pre-built ones but there's an issue where the pre-built ones
don't work on OS X.  In order to do this you need to have SWIG installed,
autoconf and libtool.  Once you've done that starting with a fresh extracted
tarball run:

./autogen.sh

>From there you should be able to build with the normal build process like you
did here:

> I ran configure as follows:
> 
> ./configure --prefix=/usr --with-swig --enable-swig-bindings=python
> 
> 
> Make works.  But then, when I run:
> 
> 
> make swig-py
> 
> 
> I get the following error from libtool 
> 
> 
> cd subversion/bindings/swig/python/libsvn_swig_py && /bin/sh
> /Users/fred/sandbox/subversion-52/subversion/libtool --tag=CC --silent
> --mode=link gcc  -g -O2 -rpath  -bundle -undefined dynamic_lookup -Wl,-F.
> -o libsvn_swig_py-1.la   swigutil_py.lo
> ../../../../../subversion/libsvn_client/libsvn_client-1.la
>  ../../../../../subversion/libsvn_wc/libsvn_wc-1.la
>  ../../../../../subversion/libsvn_ra/libsvn_ra-1.la
> 
> ../../../../../subversion/libsvn_delta/libsvn_delta-1.la
> 
> ../../../../../subversion/libsvn_subr/libsvn_subr-1.la
>  -L/usr/lib -R/usr/lib -laprutil-1 -lldap -llber
> -llber-lexpat -liconv-lsqlite3-lldap -llber -llber -L/usr/lib
> -R/usr/lib -lapr-1 -lpthread -framework Security -framework CoreFoundation
> -framework CoreServices
> 
> libtool: link: only absolute run-paths are allowed
> 
> make: *** [subversion/bindings/swig/python/libsvn_swig_py/libsvn_swig_py-1.la
> ] Error 1

This error doesn't look familar to me.  But I can say that I don't have an
empty -rpath with our 1.8.4 source.

> I think this is because -rpath doesn't have anything after it.  I looked at 
> the
> swig-py target in the Makefile and found the following:
> 
> swig-py: autogen-swig-py copy-swig-py
> 
> 
> I can't find the target autogen-swig-py in the Makefile.  Can anyone tell me
> where I can find this target defined?  Is there somewhere else I should look 
> to
> find why -rpath is empty above?

In the source directory in the file named build-outputs.mk (which is included
part way through the Makefile).  However, I'd suggest you not go down the dark
path of debugging the build without first trying a newer source package.

If nothing else you almost always want the newest version of the bindings since
we fix bugs in them on a regular basis.

Re: svn delete removes read-only files

[Ryan Schmidt]

On Nov 18, 2013, at 10:37, Rick Varney wrote:

> So for Redhat 5, rm does seem to give read-only files some special
> treatment.  The fact that rm on your OS does not makes me wonder if I am
> wrong about how typical this behavior is in other Linux/Unix flavors.

Both GNU rm (used on Linux) and BSD rm (used on OS X and *BSD) do this. From 
the BSD rm manpage on OS X 10.9:


DESCRIPTION
 The rm utility attempts to remove the non-direc-
 tory type files specified on the command line.
 If the permissions of the file do not permit
 writing, and the standard input device is a ter-
 minal, the user is prompted (on the standard
 error output) for confirmation.

Re: Continuous Integration

[Ryan Schmidt]

On Nov 18, 2013, at 06:37, Navindian wrote:

> I wish to create a web app and share it on SVN. I wish to use this SVN url 
> for Jenkins Integration.
> 
> Do I need to take any precautions.

I don’t understand the question.

I use Subversion and I’ve develop web sites whose code I’ve stored in a 
Subversion repository, but I haven’t used Jenkins. Perhaps you could explain 
what role you want Jenkins to play, and why you think it will be a problem.

Re: svnsync: properties not always copied?

[Dustin Lang]

Hi Mark,

I do not want to sidetrack this discussion and it sounds like you are 
not having the issue I am going to mention, but I thought you could not 
rely on this any more due to the random hash ordering of APR in recent 
releases (which would yield different md5sum)?


At one point I put in a local patch to fix the order of deletes.  I 
thought I sent a note and the patch to the list.  That was ages ago.


(Patch: http://astrometry.net/svn/trunk/scripts/svnsync/sort-dels.diff, 
but I don't know if it still applies or is needed)


cheers,
--dustin

RE: svnsync: properties not always copied?

[Dustin Lang]

Dear Bert,

Thanks very much for your reply.  I was also frustrated that I was not 
able to create a small test case that reproduces the problem, hence my 
plea for ideas of what could be triggering the problem.


Your example 'svn:mergeinfo' missing could be caused by older Subversion 
clients that in some specific merge cases committed unmodified 
properties as modified.


You nailed it!

The machine where I normally make the tags like the one in the example I 
sent is at svn 1.6.


I just tested, and when I tag with a v1.6 client, the svnadmin dumps 
differ between the original and mirror, while when I tag with a v1.8.4 
client, the svnadmin dumps are identical.


NICE!

Thanks very much,
--dustin

Re: svnsync: properties not always copied?

[Mark Phippard]

On Mon, Nov 18, 2013 at 12:10 PM, Dustin Lang  wrote:


> I keep an svnsync'd mirror of my svn repository, and I run a very
> stringent verification check: I do an "svnadmin dump" on the original and
> the mirror, and demand that they have the same md5sum.  It is paranoid, but
> paranoia is good when it comes to backups!
>
>
I do not want to sidetrack this discussion and it sounds like you are not
having the issue I am going to mention, but I thought you could not rely on
this any more due to the random hash ordering of APR in recent releases
(which would yield different md5sum)?

Did we "fix" all of our hashes to apply an ordering of the results?  I
believe it was discussed but did not know if we ever implemented it
everywhere.  The 1.8 Release Notes list this:

* fix dependency on APR hash order in several logic paths (r1338350 et al)



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: svnsync: properties not always copied?

[Bert Huijben]

> -Original Message-
> From: Dustin Lang [mailto:dstnd...@gmail.com] On Behalf Of Dustin Lang
> Sent: maandag 18 november 2013 18:10
> To: users@subversion.apache.org
> Subject: svnsync: properties not always copied?
> 
> 
> [I am not on the list; please cc me in replies]
> 
> Hi,
> 
> I keep an svnsync'd mirror of my svn repository, and I run a very
> stringent verification check: I do an "svnadmin dump" on the original and
> the mirror, and demand that they have the same md5sum.  It is paranoid,
> but paranoia is good when it comes to backups!
> 
> Problem is, in some situation that I haven't nailed down, some properties
> don't seem to get set in the svnsync'd version.  I think it happens when I
> make a tag, ie, copy a directory, that has properties set.  For example,
> in the "svnadmin dump":

Hi Dustin,

Your description of your problem sounds like something that might be very
important to fix, but it doesn't describe a way for us to reproduce the
problem. This makes it very hard for us to spend time on this issue.

Your example 'svn:mergeinfo' missing could be caused by older Subversion
clients that in some specific merge cases committed unmodified properties as
modified. When the replay code then calculates which property changes should
be reported, the no-change properties are not reported.
(All known cases of this problem should be fixed in Subversion 1.8.X
clients)

So there might be changes that are no real changes in the lower fs layers of
subversion that would be noted as 'no change' by the upper layers, which
could explain exactly what you are seeing: a difference between dumping via
the lower and higher layers.


Is there some way you can show us how you find the problem or how we can
reproduce the problem. That way we can try to find the root cause, and see
if there is something we can fix.


--
If you want to try reproducing the case I described here you need a
Subversion 1.7 or older client and merge directories that contain
properties. Subversion 1.7 will then just commit the properties that were
copied, as if they were locally changed into what they were before they were
copied.

As normal user you would probably never notice this problem... But we found
out about it when fixing some tree conflict cases in merging during 1.8
development.
--

Thanks,
Bert



> 
> 
> Node-path: tags/nova/2013-11-04-1
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 24017
> Node-copyfrom-path: trunk/src/astrometry
> Prop-content-length: 92
> Content-length: 92
> 
> K 10
> svn:ignore
> V 6
> *.pyc
> 
> K 13
> svn:mergeinfo
> V 30
> /tags/nova/2012-06-27-2:21009*
> PROPS-END
> 
> 
> in the svnsync'd mirror:
> 
> 
> Node-path: tags/nova/2013-11-04-1
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 24017
> Node-copyfrom-path: trunk/src/astrometry
> 
> 
> This sounds a bit like closed issue 4184:
>http://subversion.tigris.org/issues/show_bug.cgi?id=4184
> 
> I am using subversion-1.8.4.
> 
> For what it's worth, the mirror is on another machine and connects via
> svn+ssh.  This svn repo was created in 2005, and is format "3" (versions
> 1.5+).
> 
> Unfortunately, I was unable to create a simple test case demonstrating the
> problem, so maybe it is some more complicated circumstance than the
> properties and directory copy, or maybe it has to do with having an old
> repo?
> 
> Any hints on what could trigger this would be much appreciated!
> 
> Thanks,
> --dustin

RE: Looking into using Subversion

[vanderWalt . Devlyn]

Thanks again Andrew, I did try TorstiseSVN today, and it working great
for me.

Enjoy
Devlyn


From:   Andrew Reedick 
To: "vanderwalt.dev...@columbus.co.za" 
, Ben Reser 
Cc: Chris Shelton , Nico Kadel-Garcia 
, Subversion , 
"bob.arc...@amsi.com" 
Date:   2013/11/19 04:15 PM
Subject:RE: Looking into using Subversion





> From: vanderwalt.dev...@columbus.co.za [
mailto:vanderwalt.dev...@columbus.co.za] 
> Sent: Tuesday, November 19, 2013 1:47 AM
> To: Ben Reser
> Cc: Chris Shelton; Nico Kadel-Garcia; Subversion; bob.arc...@amsi.com; 
Andrew Reedick
> Subject: Re: Looking into using Subversion
>
> Thank you all, Chris Bob, Andrew, Ben. 
>
> Bob, the Server I am taking about here is our development, not
> production server so it will be fine.
>
> Chris, Andrew, and Ben thank you for given me 3 solutions to explore.
>
> I think I am going to give Subversion try, only thing I am not too keen
> about is the command line interface.  Our developers here would
> prefer a GUI client, any good ones you can suggest? 

The important thing is to use a 1.8.x client for the improved merging, 
i.e. not having to use the --reintegrate switch with 'svn merge' anymore.
 
TorstiseSVN on Windows is great.  Subclipse supports 1.8.x and works. 
However, last I checked, NetBeans requires you to set the subversion 
plugin to use the 1.8.x CLI instead of javahl or svnkit (which are limited 
to 1.7.)

Again, last I checked, non-windows GUI clients also have the problem of 
being stuck at 1.7.x.



-
This e-mail is subject to the Columbus Stainless [Pty] Ltd Email Legal Notices 
available at: http://www.columbus.co.za/EmailLegalNotice.htm.
-

This e-mail message has been scanned for Viruses and Content and cleared by 
MailMarshal
-

RE: Looking into using Subversion

[Andrew Reedick]

> From: vanderwalt.dev...@columbus.co.za 
> [mailto:vanderwalt.dev...@columbus.co.za] 
> Sent: Tuesday, November 19, 2013 1:47 AM
> To: Ben Reser
> Cc: Chris Shelton; Nico Kadel-Garcia; Subversion; bob.arc...@amsi.com; Andrew 
> Reedick
> Subject: Re: Looking into using Subversion
>
> Thank you all, Chris Bob, Andrew, Ben. 
>
> Bob, the Server I am taking about here is our development, not
> production server so it will be fine.
>
> Chris, Andrew, and Ben thank you for given me 3 solutions to explore.
>
> I think I am going to give Subversion try, only thing I am not too keen
> about is the command line interface.  Our developers here would
> prefer a GUI client, any good ones you can suggest? 

The important thing is to use a 1.8.x client for the improved merging, i.e. not 
having to use the --reintegrate switch with 'svn merge' anymore.
 
TorstiseSVN on Windows is great.  Subclipse supports 1.8.x and works.  However, 
last I checked, NetBeans requires you to set the subversion plugin to use the 
1.8.x CLI instead of javahl or svnkit (which are limited to 1.7.)

Again, last I checked, non-windows GUI clients also have the problem of being 
stuck at 1.7.x.