Re: Working SRPM and .spec files for subversion-1.7.1
On Fri, Oct 28, 2011 at 11:32:52PM -0400, Nico Kadel-Garcia wrote: > For various reasons, I've been working on RPM packaging of 1.7.0 and > now 1.7.1. I'd like to get the old "packages/rpm" structure replaced > with it, and I'm trying to get it into RPMforge. It's built from the > Fedora packaging of subversion-1.6.17, and most of the patches are no > longer needed (because they're for the "contrib" utilities". > > What's the best way to get that submitted? The .spec file is aobut 36 > K, the single patch file (for an old Debian reported bug) is about 12 > K. Send a patch (created with 'svn diff') + log message. Size of the patch doesn't matter. See http://subversion.apache.org/docs/community-guide/general.html#patches
Re: svnlook issue
Please Reply All so this discussion stays on the mailing list. On Oct 29, 2011, at 03:09, Bruce Vining wrote: > Thx for the quick response. What is the layout of the "format" file. Is it > part of the SVN system or is this a file I create for each of my repositories? > > Thx again for the 411. The "format" file is inside every repository you create. It tells Subversion what kind of repository it is. $ svnadmin create somerepository $ ls -1 somerepository README.txt conf db format hooks locks Do your repositories not look the same?
Re: Working SRPM and .spec files for subversion-1.7.1
Thanks, Stefan! I'm noticing a KWallet software detection bug, My test setup is RHEL 5, which doesn't have a recent enough KDE to support KWallet, so the .spec file works there. It *won't* work for current Fedora releases or RHEL 6, because the KWallet description causes "./configure --with-kwallet" to fail. But that's a separate issue. On Sat, Oct 29, 2011 at 7:06 AM, Stefan Sperling wrote: > On Fri, Oct 28, 2011 at 11:32:52PM -0400, Nico Kadel-Garcia wrote: >> For various reasons, I've been working on RPM packaging of 1.7.0 and >> now 1.7.1. I'd like to get the old "packages/rpm" structure replaced >> with it, and I'm trying to get it into RPMforge. It's built from the >> Fedora packaging of subversion-1.6.17, and most of the patches are no >> longer needed (because they're for the "contrib" utilities". >> >> What's the best way to get that submitted? The .spec file is aobut 36 >> K, the single patch file (for an old Debian reported bug) is about 12 >> K. > > Send a patch (created with 'svn diff') + log message. > Size of the patch doesn't matter. > See http://subversion.apache.org/docs/community-guide/general.html#patches >
Where/How to get a Test Subversion Server
In need of breaking the initial ice with Subversion, I wonder if you have any real knowledge of a Test Subversion Repository/Server where to start understanding, hands-on, what it's all about. Anyhow, these are the related generic—and, so far, untested—hints I've already collected: -- Redbean book -- CollabNet -- Subversion Edge -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com -- GUI client TortoiseSVNThat said in case you know any better. Thank you. - P.M.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 05:07:13PM +, Pietro Moras wrote: > In need of breaking the > initial ice with Subversion, I wonder if you have any real knowledge > of a Test Subversion Repository/Server where to start understanding, > hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: -- Redbean book -- CollabNet -- Subversion Edge -- Trial > Subversion > server at: SpringLoops.com, Beanstalkapp.com -- GUI client > TortoiseSVNThat said in case you know any better. Thank you. - P.M. > There is no need to set up a server to try out Subversion. Install TortoiseSVN 1.7.1. Create a new directory C\:repos. Right-click on that directory, pick "TortoiseSVN->Create repository here" This gives you a repository to play with on the local machine. You can access it with TortoiseSVN, and other clients, with this URL: file:///C:/repos Please read Chapter 2 of the red-bean book before proceeding. It explains the basics quite well.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: > In need of breaking the initial ice with Subversion, I wonder if you have > any real knowledge of a Test Subversion Repository/Server where to start > understanding, hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: > > -- Redbean book > > -- CollabNet > > -- Subversion Edge > > -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com > > -- GUI client TortoiseSVN > > That said in case you know any better. Pretty much everything you can do with subversion will work with a local repository and file:/// references. Do your initial testing/learning that way, then decide what OS platform you want for your server. I'd recommend a linux distribution where it would be included in the standard system and updates, but that's a matter of preference. You should not see any differences from the client side regardless of the server platform. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
>> In need of breaking the >> initial ice with Subversion, I wonder if you have any real knowledge >> of a Test Subversion Repository/Server where to start understanding, >> hands-on, what it's all about. > > There is no need to set up a server to try out Subversion. > > Install TortoiseSVN 1.7.1. Create a new directory C\:repos. > Right-click on that directory, pick "TortoiseSVN->Create repository here" > > This gives you a repository to play with on the local machine. > You can access it with TortoiseSVN, and other clients, with this URL: > file:///C:/repos But IF You want to test client-server way of working, be sure to select command line tools during TortoiseSvn install. Then You can create a bat file with svnserve -d -r c:\repos and when that is started, connect to server with URL svn://localhost/ Keep in mind that anyone can access the repository if they know your host/ip and can reach to it from their computer (I.e. whole internet if there is no firewall/NAT in between), so some access or firewall configuration might be needed. It is pretty easy to install svnserve as windows service also, so basically You just need TortoiseSVN to have a full set of svn server/client software. Gert
RE: svnlook issue
Ryan, First of all, let me offer my sincerest gratitude. Your latest email made very clear the "error of my ways". I thought the /format folder lived in the source folder with the /trunk, /branches, /tag folders. You now cleared it up for me that the /format folder lives under the repository on the SVN server. This also brings into focus other postings I found while surfing Google for the /format issue I was experiencing. As directed by the other postings, I set the permissions on the /format folder (for all my repositories) to RW for all mod levels and it corrected the problem. Again, much thanks for the immediacy of your response and clearing up the issue for me. I do perform syncing across servers and am now getting the following: "svnsync: warning: W27: Target server does not support atomic revision property edits; consider upgrading it to 1.7 or using an external locking program" I will work this, it is apparent that the versioning does not agree now between my updated local master-sync SVN server and the original remote slave-sync SVN server. Thanks again for all your help. Regards, Bruce Vining - Sr. Member IEEE, VCP, CCSP, CCNA, MCSE Owner, Senior Systems Engineer, Secure Digital Solutions * bvin...@securedigitalsolutions.biz Office: (205) 467-2101 Cell: (205) 821-8765 http://www. securedigitalsolutions.biz -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Saturday, October 29, 2011 6:34 AM To: Bruce Vining Cc: Subversion Users Subject: Re: svnlook issue Please Reply All so this discussion stays on the mailing list. On Oct 29, 2011, at 03:09, Bruce Vining wrote: > Thx for the quick response. What is the layout of the "format" file. Is it part of the SVN system or is this a file I create for each of my repositories? > > Thx again for the 411. The "format" file is inside every repository you create. It tells Subversion what kind of repository it is. $ svnadmin create somerepository $ ls -1 somerepository README.txt conf db format hooks locks Do your repositories not look the same?
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 10:52 AM, Stefan Sperling wrote: > There is no need to set up a server to try out Subversion. > On Sat, Oct 29, 2011 at 11:03 AM, Les Mikesell wrote: > > Pretty much everything you can do with subversion will work with a > local repository and file:/// references. Do your initial > testing/learning that way Sort of off topic of this thread, but even though I've used SVN for years, the idea of running it locally without a server never occurred to me. I thought 'distributed repositories' was Git's only/main benefit over SVN, but if you have a local repository, I'm guessing you can work/commit locally, then svn switch to your remote/work repository to commit to the shared/compay repo? Is that right?
Re: Where/How to get a Test Subversion Server
Try this on a Unix-like system: cd ~ svnadmin create /myrepo svn checkout file:///myrepo When you're done playing, rm -rf /myrepo rm -rf ~/myrepo - Original Message - From: Les Mikesell Sent: 10/30/11 04:03 AM To: Pietro Moras Subject: Re: Where/How to get a Test Subversion Server On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: > In need of breaking the initial ice with Subversion, I wonder if you have > any real knowledge of a Test Subversion Repository/Server where to start > understanding, hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: > > -- Redbean book > > -- CollabNet > > -- Subversion Edge > > -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com > > -- GUI client TortoiseSVN > > That said in case you know any better. Pretty much everything you can do with subversion will work with a local repository and file:/// references. Do your initial testing/learning that way, then decide what OS platform you want for your server. I'd recommend a linux distribution where it would be included in the standard system and updates, but that's a matter of preference. You should not see any differences from the client side regardless of the server platform. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 01:40:11PM -0700, Geoff Hoffman wrote: > Sort of off topic of this thread, but even though I've used SVN for years, > the idea of running it locally without a server never occurred to me. I > thought 'distributed repositories' was Git's only/main benefit over SVN, > but if you have a local repository, I'm guessing you can work/commit > locally, then svn switch to your remote/work repository to commit to the > shared/compay repo? Is that right? No. In Subversion, revision numbers are per-repository. Your local repository has a distinct revision number space from the shared/company repository. So each repository is its own universe. In Git revisions are global across multiple repositories. A universe is made up of a number of repositories, each cloned from one another. The file:// access method is intended for testing purposes mostly. Though nothing prevents you from working with a repository locally via file:// for a while, and later network this same repository to the world, for instance via https.
KWallet detection bug in Subverson-1.7.1 for RHEL 6 and Fedora
The recent versions of RHEL 6 and Fedora install KDE as distinct kde3
or kde4 setups in /usr/include/{kde3,kde4} and
/usr/lib[64]/{kde3,kde4}/devel. The result confuses the
build/ac-macros/kwallet.m4 macros. While splitting the "kde_dir" test
into separate tests for "kde4--config --path include" and "kde4-config
--path lib" may work well in other, more simply configured
distributions, for RHEL and Fedora, it's a problem.
The published RPM's for subversion-1.6.17 on Fedora had their own
patch, but it's not suitable for subversion-1.7.1. So I've written and
tested the one below. The "kde4/devel" bit is Fedora/RHEL specific. If
it's not suitable for the main codeline, it should at least go in a
new "packages/rpm/rhel-6" location. I'll try to get an updated set of
tools for those as well: Rewriting the "Makefile" there to not blow
away .rpmmacros but correctly bundle the software is... interesting.
subversion-1.7.1/build/ac-macros/kwallet.m4 (revision 1187723)
+++ subversion-1.7.1/build/ac-macros/kwallet.m4 (working copy)
@@ -64,15 +64,15 @@
fi
done
qt_include_dirs="`$PKG_CONFIG --cflags-only-I
QtCore QtDBus QtGui`"
- kde_dir="`$KDE4_CONFIG --prefix`"
- SVN_KWALLET_INCLUDES="$DBUS_CPPFLAGS
$qt_include_dirs -I$kde_dir/include"
+ kde_inc_dir="`$KDE4_CONFIG --path include`"
+ SVN_KWALLET_INCLUDES="$DBUS_CPPFLAGS
$qt_include_dirs -I$kde_inc_dir"
qt_libs_other_options="`$PKG_CONFIG
--libs-only-other QtCore QtDBus QtGui`"
SVN_KWALLET_LIBS="$DBUS_LIBS -lQtCore -lQtDBus
-lQtGui -lkdecore -lkdeui $qt_libs_other_options"
CXXFLAGS="$CXXFLAGS $SVN_KWALLET_INCLUDES"
LIBS="$LIBS $SVN_KWALLET_LIBS"
qt_lib_dirs="`$PKG_CONFIG --libs-only-L QtCore QtDBus QtGui`"
- kde_lib_suffix="`$KDE4_CONFIG --libsuffix`"
- LDFLAGS="$old_LDFLAGS
`SVN_REMOVE_STANDARD_LIB_DIRS($qt_lib_dirs
-L$kde_dir/lib$kde_lib_suffix)`"
+ kde_lib_dir="`$KDE4_CONFIG --path lib | awk -F:
'{print $(NF)}'`/kde4/devel"
+ LDFLAGS="$old_LDFLAGS
`SVN_REMOVE_STANDARD_LIB_DIRS($qt_lib_dirs -L$kde_lib_dir)`"
AC_LANG(C++)
AC_LINK_IFELSE([AC_LANG_SOURCE([[
#include
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 2:03 PM, Les Mikesell wrote: > On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: >> In need of breaking the initial ice with Subversion, I wonder if you have >> any real knowledge of a Test Subversion Repository/Server where to start >> understanding, hands-on, what it's all about. >> >> Anyhow, these are the related generic—and, so far, untested—hints I've >> already collected: >> >> -- Redbean book >> >> -- CollabNet >> >> -- Subversion Edge >> >> -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com >> >> -- GUI client TortoiseSVN >> >> That said in case you know any better. > > Pretty much everything you can do with subversion will work with a > local repository and file:/// references. Do your initial > testing/learning that way, then decide what OS platform you want for > your server. I'd recommend a linux distribution where it would be > included in the standard system and updates, but that's a matter of > preference. You should not see any differences from the client side > regardless of the server platform. Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, or svn+ssh, and backup to a second server. These are in fact some of the most awkward features to negotiate in a shared enviornment.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia wrote: > >> Pretty much everything you can do with subversion will work with a >> local repository and file:/// references. Do your initial >> testing/learning that way, then decide what OS platform you want for >> your server. I'd recommend a linux distribution where it would be >> included in the standard system and updates, but that's a matter of >> preference. You should not see any differences from the client side >> regardless of the server platform. > > Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, > or svn+ssh, and backup to a second server. These are in fact some of > the most awkward features to negotiate in a shared enviornment. Yes, but the packaged linux versions pretty much just come up working under http(s) with a appropriate line or two added to the packaged configuration to point to the repository location, and once a network server works, svnsync 'just works' to back it up from elsewhere. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 9:56 PM, Les Mikesell wrote: > On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia wrote: >> >>> Pretty much everything you can do with subversion will work with a >>> local repository and file:/// references. Do your initial >>> testing/learning that way, then decide what OS platform you want for >>> your server. I'd recommend a linux distribution where it would be >>> included in the standard system and updates, but that's a matter of >>> preference. You should not see any differences from the client side >>> regardless of the server platform. >> >> Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, >> or svn+ssh, and backup to a second server. These are in fact some of >> the most awkward features to negotiate in a shared enviornment. > > Yes, but the packaged linux versions pretty much just come up working > under http(s) with a appropriate line or two added to the packaged > configuration to point to the repository location, and once a network > server works, svnsync 'just works' to back it up from elsewhere. Les, I'm afraid that's handwaving. Like implementing Wikis and FTP sites, it leaves out the boobytraps. Let's look specifically at the HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good, and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has the profound flaw that it explicitly recommends creating the repositories owned by the "apache" user. But this leaves not merely the Subversion database, but the *configuration* and hook scripts for the Subversion repository owned by the "apache" user, so any other PHP script or poorly secured services running on that HTTP server can edit *anything* in the Subversion repository, unmanaged by and unknown to the repository maintainer. Worse, there are setups where both HTTP and SSH are used to access the same repository. And suddenly pre-commit and post-commit scripts can be manipulated by another HTTP "apache" owned process, and later get run if *root* comes in via SSH. And *THAT* is a disaster waiting to happen Looking this stuff up in Google, or in the Red Book for Subverson, is not enough because the answers are incomplete. or disjoint, and often contradictory The underlying and historically evident attitude is that "security is your problem, you have to trust he machine you're working on". So summing up: simple "file:///" access is not going to properly introduce you to these issues.
