Re: svnadmin failure on nearly identical system

[Andy Canfield]

On 07/22/2011 10:20 AM, Ryan Schmidt wrote:

On Jul 21, 2011, at 22:09, Andy Canfield wrote:


I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I have 
the same system installed on my desktop computer named Athol (I had a lot of 
trouble getting that hardware to work). I have installed the Ubuntu Subversion 
packages on each; namely
 subversion
 libapache2-svn
 libgirepository-1.0-1
In both cases the SVNParentPath is /data/svn and that directory is owned by 
www-data:
 drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn

Here is the critical command:
 sudo -u www-data svnadmin create /data/svn/boofar
On Lenny the command works, silently. On Athol I get this message:
svnadmin: error while loading shared libraries: libsvn_repos-1.so.0:
  cannot open shared object file: No such file or directory
Apparently svnadmin cannot find something, but I don't know what it can't find. 
In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to:
 -rw-r--r-- 1 root root 153700 2011-06-05 22:48 
/usr/lib/libsvn_repos-1.so.1.0.0

I Googled for that error message and somebody had a problem with the home directory 
locations. The implication was that for some reason a Subversion distribution hard-codes 
the name of the home directory parent path (e.g. "/home"). No problem with my 
home directories; the arrangement is identical. On both machines my home directory is 
/data/andy and /home/andy is a symbolic link to /data/andy.

So any idea why svnadmin runs OK on one machine and fails on the other?

Is there perhaps a second (older) copy of Subversion or its libraries 
installed, perhaps provided by your distribution? If so, try uninstalling that.

Nope; I installed subversion on Athol yesterday, and I run apt-get 
upgrade frequently.


UPDATE - ANOTHER TEST

I used 'tar' to move /data/svn/sample3 - an existing repository - from 
Lenny to Athol. Now I can point my browser to http://athol/svn/sample3 
and see the usual status screen. For command on Lenny:

*svn info http://localhost/svn/sample3*
The response is:
*Authentication realm:  Lenny Subversion Repository
Password for 'andy':
Path: sample3
URL: http://localhost/svn/sample3
Repository Root: http://localhost/svn/sample3
Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)
*FOr this command on Lenny:
*svn info http://athol/svn/sample3*
The response is:
*Authentication realm:  Athol Subversion Repository
Password for 'andy':
Path: sample3
URL: http://athol/svn/sample3
Repository Root: http://athol/svn/sample3
Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)*
But this command on Athol:
*svn info http://localhost/svn/sample3
*gives this error result:
*vn: error while loading shared libraries: libsvn_client-1.so.0:
cannot open shared object file: No such file or directory*

*So the problem is in the client, not on the apache server.
And both svnadmin and svn show the same problem.*

=
FOUND IT!
God knows where it came from, but there was a set of svn* programs in 
/usr/local/bin.

Erased them all and now it works.
Thank you very much; this counts as success for today.

Re: Need for a local Subversion server?

[Andreas Krey]

On Sat, 23 Jul 2011 11:52:12 +, Stefan Sperling wrote:
...
> You can branch and merge locally in git, but all the git branches you
> create in the git repository cloned from svn usually map to one Subversion
> branch. If they don't then you need to add merges between branches
> to svn:mergeinfo when you push revisions to Subversion.
> 
> This is possible with recent git-svn versions, but you have to manually
> pass the correct svn:mergeinfo value (the *full* value, not just the
> modifications your merge is creating!). ..  But manually
> computed mergeinfo can still be wrong even if it is syntactically correct.

And are very likely to get wrong. May it be possible to first do
the merge via git-svn, and then fix the mergeinfo with 'svn merge
(--reintegrate) --record-only'?  One would need to 'git svn fetch' and
clean up afterwards, but have the advantages of git's merge algorithms.

...
> If your use of git-svn does not involve merging between Subversion
> branches it is probably safe.

I usually use git-svn for 'regular' in-branch work, and fall back to svn
for merges (the few I need to do).

Also git-svn comes in quite handy, along with gitk, to visualize branches
and merges in svn, and to simply see from where tags have been made
(trunk or some branch).

Is there some visualization that can do the same for svn natively,
for a whole tree (as opposed to single files).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

best strategy for long-living branches / reflective merges

[Tino Schwarze]

Hi there,

I'm looking for a best practice for the following situation: We have
several long-living product branches forked off a common trunk. They
cannot closely follow trunk, that is, merging often from trunk is not an
option.

Bugfixes and some features need to be backported to trunk, though. Which
is, as I have learned recently, not explicitly supported by Subversion.
(Developing those bugfixes and/or features in trunk is also not an
option for various reasons.) After reading several articles and
discussions I came to the conclusion that the best practice would be to 
svn merge --ignore-ancestry from child to trunk, while manually
selecting the changes (e.g. by revision) we want in trunk. That is,
these "merges" need to be tracked manually.

If we provide some helper scripts, the revision resulting from that
merge could be --record-only merged back to the child so we won't get
conflicts later.

Correct?

Now, if a major product version goes EOL, we could simply create a
"reintegration branch" from it's main branch to perform the trunk->child
merge there and use --reintegrate afterwards to get all
not-yet-integrated changes back to trunk, right? (The extra branch is
used so the product's main branch won't get disturbed and is still
available for bugfixing etc. While I'm thinking about it - would it be
possible to always keep that branch and it gets changes from trunk and
the product's main branch from time to time so we can reintegrate the
product's current state into trunk more often?)

To rephrase that question, is it okay to have these branches:
/trunk
/prodA
/prodA/reintegration
and to integrate changes in /prodA to trunk without merging from trunk
first, do merge /prodA -> /prodA/reintegration, then do merge /trunk ->
/prodA/reintegration, then reintegrate-merge /prodA/reintegration to
/trunk? Would Subversion handle that or problems ahead?

Thanks for any input,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.tisc.de

SVN 1.7

[Mario Brandt]

I installed SVN/1.7.0-beta2 using it over apache 2.3.12, also tried
the alphas before. With none of it I'm able to use SVNParentPath. I'm
gettin

Could not open the requested SVN filesystem


the same error if that wouldn't be a repo instead of showing the list of repos.

my config
   
DAV svn
SVNParentPath "/opt/repos"
SVNListParentPath on
SVNPathAuthz on
#SVNIndexXSLT "/svnindex.xsl"

AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /opt/repos/htpasswd
Require valid-user


With apache 2.2.19 and SVN 1.6.17 I can see the repo list.

How can I make it work?

Cheers
Mario

copying subdirectories in subversion 1.7

[Ryan Brothers]

I just tried out the new Subversion 1.7 beta today and had a question 
regarding the new working copy format:


With the Subversion 1.6 working copy format, since a .svn directory was 
in every directory, I would sometimes take advantage of the fact that a 
subdirectory could be copied out of a checkout and made into a new 
top-level checkout.


For example, if a project called test was checked out into 
c:\checkouts\test and it has a subdirectory called module1, I could copy 
module1 into c:\checkouts\module1 using a regular filesystem copy and 
use it as a full top-level checkout.


With the new 1.7 working copy format, if I did the same copy, I won't 
get the .svn folder of course.


Is there a way to create a new top-level checkout of a subdirectory with 
the 1.7 working copy format?  I realize that I can always just do a 
fresh checkout from the server for the subdirectory, but looking to see 
if there's a way I can use the local filesystem since I already have the 
files checked out, especially if it's a large checkout.


Thanks,
Ryan

Re: copying subdirectories in subversion 1.7

[Daniel Shahaf]

Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400:
> Is there a way to create a new top-level checkout of a subdirectory
> with the 1.7 working copy format?

Just copying a dir isn't supported.  (the plan has been to provide a new
subcommand for that, but that won't happen before 1.8)

You might be able to duplicate the whole wc and do 'svn switch' to the
subdirectory's URL (which will tell you to pass --ignore-ancestry), but
I'm not sure how much server communication will be done in that case.
(it will certainly contact the server, since without '-r' switch always
assumes '-r HEAD')

Re: copying subdirectories in subversion 1.7

[Ryan Schmidt]

On Jul 24, 2011, at 16:57, Daniel Shahaf wrote:

> Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400:
>> Is there a way to create a new top-level checkout of a subdirectory
>> with the 1.7 working copy format?
> 
> Just copying a dir isn't supported.

It worked fine in 1.6.x and earlier. I too frequently use this.

> (the plan has been to provide a new
> subcommand for that, but that won't happen before 1.8)

So 1.7 will be released with this regression in functionality?

Re: copying subdirectories in subversion 1.7

[Stefan Sperling]

On Sun, Jul 24, 2011 at 05:08:14PM -0500, Ryan Schmidt wrote:
> 
> On Jul 24, 2011, at 16:57, Daniel Shahaf wrote:
> 
> > Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400:
> >> Is there a way to create a new top-level checkout of a subdirectory
> >> with the 1.7 working copy format?
> > 
> > Just copying a dir isn't supported.
> 
> It worked fine in 1.6.x and earlier. I too frequently use this.
>
> > (the plan has been to provide a new
> > subcommand for that, but that won't happen before 1.8)
> 
> So 1.7 will be released with this regression in functionality?

It's not a regression because this "feature" was never officially
documented or advertised. It just happened to work because of the way
the old working copy was designed.  

That said, we knew people were doing this, and that shipping 1.7 without
a new 'svn detach' subcommand might impact some users who relied on this.
However, since the obvious workaround of getting a new checkout exists
development resources went into more important stuff.
So, sorry, you'll have to get a new checkout until 'svn detach' has been
implemented. See http://subversion.tigris.org/issues/show_bug.cgi?id=2884

You can also keep using 1.6.x for the time being if detaching subdirectories
is very important to you. 1.6.x is still going to supported until 1.8.0
is released.

Re: copying subdirectories in subversion 1.7

[Daniel Shahaf]

CC += dev@

Ryan Schmidt wrote on Sun, Jul 24, 2011 at 17:08:14 -0500:
> 
> On Jul 24, 2011, at 16:57, Daniel Shahaf wrote:
> 
> > Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400:
> >> Is there a way to create a new top-level checkout of a subdirectory
> >> with the 1.7 working copy format?
> > 
> > Just copying a dir isn't supported.
> 
> It worked fine in 1.6.x and earlier. I too frequently use this.
> 
> > (the plan has been to provide a new
> > subcommand for that, but that won't happen before 1.8)
> 
> So 1.7 will be released with this regression in functionality?
> 

Yes.

The 1.7 working copy format was designed to allow sharing pristines even
between working copies, and this might happen in the 1.8 timeframe; but
in 1.7 the answer is simply "No"[1].

is_wc function in svnmerge.py vs svn 1.7

[Joel N. Weber II]

https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svnmerge/svnmerge.py

contains this function:

def is_wc(dir):
"""Check if a directory is a working copy."""
return os.path.isdir(os.path.join(dir, ".svn")) or \
   os.path.isdir(os.path.join(dir, "_svn"))

which needs to be updated somehow for 1.7 working copies.  (Making it
unconditionally return True seems to be a semi-adequate workaround.)

1.7.x configure script should suggest running get-deps.sh when appropriate

[Joel N. Weber II]

At least in 1.7.0-beta2, if you run ./configure without the
appropriate dependencies available, you get an error message like the
below.  It would be helpful if this message could be adjusted to
recommend running ./get-deps.sh


configure: Apache Portable Runtime (APR) library configuration
checking for APR... no
configure: WARNING: APR not found
The Apache Portable Runtime (APR) library cannot be found.
Please install APR on this system and supply the appropriate
--with-apr option to 'configure'

or

get it with SVN and put it in a subdirectory of this source:

   svn co \
http://svn.apache.org/repos/asf/apr/apr/branches/1.3.x \
apr

Run that right here in the top level of the Subversion tree.
Afterwards, run apr/buildconf in that subdirectory and
then run configure again here.

Whichever of the above you do, you probably need to do
something similar for apr-util, either providing both
--with-apr and --with-apr-util to 'configure', or
getting both from SVN with:

   svn co \
http://svn.apache.org/repos/asf/apr/apr-util/branches/1.3.x \
apr-util

configure: error: no suitable apr found
$ 

get-deps.sh script will 404 on download of sqlite-amalgamation

[Rolf Kaiser]

Hello-

I just tried to build subversion v1.6.17 from source (on CentOS 5.5).  When
I tried to run get-deps.sh it errors out since the SQLite-amalgamation
download fails with a 404.  On http://www.sqlite.org/download.html I see
that it could download a zipfile at
http://www.sqlite.org/sqlite-amalgamation-3070701.zip but there's not a
.tar.gz version listed to compare against.  Looks like they might have
changed the download URL format.

 

If you tweak the get-deps script and download and extract the zipfile
manually then you can get underway, thought I'd just pass this on.

 

-Rolf

 

 

Re: get-deps.sh script will 404 on download of sqlite-amalgamation

[Ryan Schmidt]

On Jul 24, 2011, at 23:19, Rolf Kaiser wrote:

> I just tried to build subversion v1.6.17 from source (on CentOS 5.5).  When I 
> tried to run get-deps.sh it errors out since the SQLite-amalgamation download 
> fails with a 404.  On http://www.sqlite.org/download.html I see that it could 
> download a zipfile at  http://www.sqlite.org/sqlite-amalgamation-3070701.zip 
> but there’s not a .tar.gz version listed to compare against.  Looks like they 
> might have changed the download URL format.
>  
> If you tweak the get-deps script and download and extract the zipfile 
> manually then you can get underway, thought I’d just pass this on.

http://svn.haxx.se/users/archive-2011-07/0335.shtml