AW: SVN 1.7 - check out single file?
The possibility to check out a single file would probably be the base of checking out (or update) files that match certain criteria e.g. "*doc, *txt, *html" I opened an other thread about this. Many of my colleagues would appreciate such a functionality. Regards Thomas -Ursprüngliche Nachricht- Von: Andy Levy [mailto:andy.l...@gmail.com] Gesendet: Freitag, 1. Juli 2011 17:22 An: Andy Levy; users@subversion.apache.org Betreff: Re: SVN 1.7 - check out single file? On Fri, Jun 24, 2011 at 17:05, Stefan Sperling wrote: > On Fri, Jun 24, 2011 at 02:49:58PM -0400, Andy Levy wrote: >> With the new way WCs are managed, will it be possible to check out a >> single file, instead of having to do multiple steps with sparse >> directories just to get a single file in a directory? Looking at the >> release notes and CHANGES file, I think the answer is "no", but I need >> someone more knowledgeable to back me up here before I take the answer >> back to the person who asked me. Thanks. > > No, you still need to checkout a directory. But it sounds like the > new --parents option of svn update might help you a bit: > http://subversion.apache.org/docs/release-notes/1.7.html#update-parents We'll have to see how Tortoise implements this, as that's what most folks here are using. It's an edge case for us, it's only 2 or 3 people who are affected by the issue of too many items to check out just to update a single file.
Re: 1.7.0-alpha2 testsuite pysqlite complications with CentOS
[ Accidentally replied only to Josh, duplicating to list ] On Fri, Jul 1, 2011 at 6:32 PM, Josh Cepek wrote: > I was building the subversion 1.7.0-alpha2 pre-release in a CentOS 5.6 > environment and encountered an interesting problem with the new dependency > for python's sqlite support. > > CentOS seems to name the site python library 'sqlite' while the subversion > system expects to import 'sqlite3'. This causes the test to halt accordingly > on the first python test when the import fails. The "sqlite" package in CentOS/SL/RHEL/etc. is labeled "sqlite-3.x" and the package of development components, such as include filoes, "sqlite-devel-3.x" Have you installed those development components? What does "rpm -q sqlite-devel" say? And to avoid surprises like that, I urge you to grab the SRPM's from RPMforge or from RHEL 6 and compile them locally, just to make sure you have all the previously known dependencies before you even start. Then, when you're ready for production work, you can use "mock" or something like it to build your new RPM's in a pristine environment. (This is what I did, for years, pre-testing subversion updates to submit them to RPMforge.) I'm also going to suggest you look into Scientific Linux as your next RHEL based update: SL 6 has already been out for six months, and it's like jumping in a time machine to work with a code base that's 4 years newer. ext4 has also gotten stable, and can be a big performance improvement for large Subversion repositories. Do a clean build and start with ext4 filesystems: you won't be sorry. > I'm not sure if the solution is to have the distro packager of the > python-sqlite package update the site paths (or at least symlink sqlite3 -> > sqlite) or to patch the svntest library to handle this case. Both methods > worked as expected for me, and allowed the test suite to continue. Spec file dependencies are... interesting, and can be RHEL release specific. Look for the settings in the RPMforge versions of subversion based on the '%dist' settings. Since you're not working from an SRPM, take a look at the .spec files for their dependencies. The .spec files in swubversion itself are, unfortunately, unusable and need to be replaced with RPMforge's or RHEL's. Under *NO* circumstances should you use the rpm packaging structure in the subversion source code. It hasn't worked for years, and it replaces the software builder's.rpmmacros without warning. No build system should *ever* modify the rest of your build system without notice this way. > In the event we want to support this within the 1.7.x test suite, I've > attached a patch to svntest/__init__.py that adds an additional try clause > to import sqlite as sqlite3. I'm not sure if there are any historical > implications (read: a previously named sqlite library) to this patch. If the library components are actually named that, yeah, detecting them makes sense. Personally, I've given up on RHEL 5 based distributions. RHEL 6 based is such a massive leap forward that the older releases hardly seem worth the worth the effort: RHEL 6 came out over 3 years after RHEL 5, and RHEL 5 was already lagging behind when it was published. Don't burn your effort there. > If the Subversion devs view this as a completely upstream problem I may file > a bug there, but the chances of it getting fixed are pretty low since CentOS > just repackages what RHEL provides. RPMforge might be a better venue there. I used to publish Subversion update notes on that distribution.
Re: [perl bindings] Bizarre copy of UNKNOWN in subroutine
Sorry, I didn't. I haven't gotten the thread updates and didn't find the time to do cross-version checks of perl + swig + svn. Stéphane's patch fixes it though so I don't know if an issue is still necessary.
RPM packaging components in trunk out of date and dangerous
The RPM packaging comonents in trunk/packages/rpm are out of date, unusable, and likely to destroy a developer's build environment. They should either be completely disabled or seriously updated. There are a couple of different issues, which I'll describe in order: * All the Makefiles replace the users's $HOME/.rpmmacros without warning. This is devastating to a user who has GPG signature configurations there, or who does their RPM compilation in a non $HOME/rpm location, or who follows RHEL standard uppercase naming of the SRPMS, SPEC, RPMS, and BUILD subdirectories, because the published ".rpmmacros" file follows a non-standard lowercase layout. Instead of relying on a hard-coded .rpmmacros, the Makefiles should use "rpm --showrc" command to derive the topdir, sourcedir, etc. * The .rpmmacros file ignores the "BUILDROOT" setting common to modern RPM building environments. * The .rpmmacros file should be renamed. It should be "rpmmacros.in", so it's presence is apparent to the developer, and to show that it is *not* in fact, the actual file installed. * The .spec files should be renamed to "subversion.spec.in". These are not the .spec files and should not appear as such in Subversion source code tarballs, they are source files for building .spec files. * Modern subversion cannot be compiled on rhel-3, and that packaging should be discarded. * Modern subversion cannot be compiled on rhel-4, and that packaging should be discarded. * Modern subversion can be built on rhel-5, rhel-6, fedora, etc. Those packages can be published as *one* set using the RPMforge packages. (I'm an old contributor to those.) There are some issues with this, particularly its inclusion of the "swig-3.4.0.tar.gz" tarball for RHEL 4 compilation which doesn't even work anymore, but it's a better starting base for this packaging. I'm happy to submit these as distinct issues for the issue tracker, but in the short therm, pulling out the unusable rhel-3 and rhel-4 packaging would be a good start.
Re: Standards "Best Practice"
On Fri, Jul 1, 2011 at 11:20 AM, Andy Levy wrote: > Thanks, when my SAN guy & I are back in the office at the same time > again (later in July) I'll run this by him & see if it's anything we > can tweak for our new setup. And oh, yes! Do not consider ".snapshot" backups of your Subversion repositories to be anything but deathtraps on a busy repository. (File-based backups of databases are always awkward.) And make sure that any NetApp filesystems get created with the LANG or LOCALE set to "en.US.UTF-8", becuase multi-language issues are an adventure for CIFS access and Samba access and NFS access without a UTF compatible backend filesystem on the NetApp.
Re: Branching Questions
On Fri, Jul 1, 2011 at 11:26 AM, Geoff Hoffman wrote: > >> 3. What is the best way to lock the Trunk so only certain users can access >> it, using Hook Script or using admin tool? > > >> >> use Subversion's built-in path-based authorization or >> possibly some Apache configuration tweaks > > > I just followed this guide yesterday, coincidentally, and it worked > perfectly > http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/ > Not that it's utterly useless for file:/// or svn_ssh:/// based access, and if you support those separate access methods in parallel or instead of HTTP/WebDAV based access, you'll need to rethink your acess control.
Re: Branching Questions
Could you please be more precise? svn+ssh:// is completely fine (if you configure authorized_keys(5) correctly), it's admins who give their users filesystem write access to the repository directory who are the problem. Nico Kadel-Garcia wrote on Sat, Jul 02, 2011 at 11:59:44 -0400: > On Fri, Jul 1, 2011 at 11:26 AM, Geoff Hoffman > wrote: > > > >> 3. What is the best way to lock the Trunk so only certain users can access > >> it, using Hook Script or using admin tool? > > > > > >> > >> use Subversion's built-in path-based authorization or > >> possibly some Apache configuration tweaks > > > > > > I just followed this guide yesterday, coincidentally, and it worked > > perfectly > > http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/ > > > > Not that it's utterly useless for file:/// or svn_ssh:/// based > access, and if you support those separate access methods in parallel > or instead of HTTP/WebDAV based access, you'll need to rethink your > acess control.
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Please send this to dev@, it's more likely to get some attention there.
http://subversion.apache.org/patches
Thanks
Stéphane Gaudreault wrote on Fri, Jul 01, 2011 at 18:00:18 -0400:
> Le 20 juin 2011 15:28:32, Stefan Sperling a écrit :
> > On Mon, Jun 20, 2011 at 09:54:12AM -0400, Stéphane Gaudreault wrote:
> > > Le 19 juin 2011 13:53:12, Stefan Sperling a écrit :
> > > > On Sun, Jun 19, 2011 at 07:43:31PM +0200, Otto Allmendinger wrote:
> > > > > So does this qualify as a proper bug? Can I add this to the issue
> > > > > tracker?
> > > >
> > > > Yes, please add it.
> > > >
> > > > Someone will need to pin down where the problem is coming from.
> > > > Is it SWIG? Is it Perl? Is it Subversion?
> > > >
> > > > Can you try to reproduce the problem with an earlier version of
> > > > SWIG and/or Perl?
> > >
> > > Hi,
> > >
> > > We think that only 32 bits systems are affected by this bug because
> > >
> > > cd subversion-1.6.17/subversion/bindings/swig/perl/native; make test
> > >
> > > fails on i686, but works on x86_64[1].
> > >
> > > We have that problem with either swig 2.0.3 or 2.0.4. We had no problem
> > > with perl v5.12.3. The problem was noticed after the upgrade to v5.14.0.
> > > Someone suggested that the problem could be related to the use of 64bits
> > > offset by perl [2].
> > >
> > > Regards,
> > >
> > > Stéphane Gaudreault
> > >
> > > [1] https://bugs.archlinux.org/task/24540
> > > [2] http://www.gossamer-threads.com/lists/perl/porters/263222
> >
> > Are you sure the test failures referenced in [2] are related to
> > the "bizarre copy of UNKNOWN" problem? I don't see that error
> > appearing in [2].
> >
> > But if your are sure it's related, the link at [2] clearly explains
> > that perl and extensions were compiled in an incompatible way:
> >
> > "I doubt there's anything crucial about the particular flag, but rather
> > it's the fact that you're building extensions using flags that give
> > you code that is binary incompatible with the perl binary it's being
> > built against."
> >
> > "With options like -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64' used
> > to build Perl but dropped when testing extension building, you could
> > be getting a different and incompatible stat structure or other binary
> > incompatible differences between the extension and the Perl core. "
> >
> > Which is right. Any software that shares data structures needs the
> > data structures to be compatible. Else it crashes and whatnot.
> >
> > So is this "bizarre copy of UNKNOWN" problem showing anywhere else than
> > Debian and Arch Linux? Maybe it's a problem with how these distributions
> > compile perl and related software? Maybe Perl is compiled with support
> > for large files but Subversion is not, or something like that?
>
>
> Hi,
>
> Our collegue Marcela Mašláňová from the Red Hat team suggested that the
> problem might be in in Makefile.PL where ExtUtils::MakeMaker overwrite the
> CCFLAGS. The following patch fix the problem for us. Could you please apply
> it
> ?
>
> Regards,
>
> --
> Stéphane Gaudreault
> ArchLinux developer
>
> ===
> diff -Naur
> subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in
> subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in
> --- subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in
>
> 2010-11-24 20:42:16.0 +
> +++ subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in
>
> 2011-07-01 20:16:16.520892074 +
> @@ -43,7 +43,7 @@
> my %config = (
> ABSTRACT => 'Perl bindings for Subversion',
> DEFINE => $cppflags,
> -CCFLAGS => $cflags,
> +CCFLAGS => $Config{ccflags},
> INC => join(' ',$apr_cflags, $apu_cflags,
> " -I$swig_srcdir/perl/libsvn_swig_perl",
> " -I$svnlib_srcdir/include",
Re: Branching Questions
On Sat, Jul 2, 2011 at 5:17 PM, Daniel Shahaf wrote: > Could you please be more precise? svn+ssh:// is completely fine (if you > configure authorized_keys(5) correctly), it's admins who give their > users filesystem write access to the repository directory who are the > problem. I consider svn+ssh the closest thing to remotely securable access for Subversion. I didn't mean to deprecate it in any way. I may have misunderstood the phrase "possibly some Apache configuration tweaks" to mean doing path based control on the Apache server side. This is surprisingly common: I've been forced to use it several times for employers. The problem is that if it's done purely in the Apache configuration, that access control will have no affect on file:// or svn+ssh:// based access, and this is actually what the "Subversion Red Book" describes. svnserve path based access control, which is what svn+ssh uses, is entirely distinct from Apache access control in the examples. I've not personally used both at the same time because the security model winds up very confused. Getting Subversion services under "suexec" doesn't work, and putting in authorized_keys for the apache daemon owner gets... crazy making. So you wind up doing things like common group ownership and sgid directory settings, which are *not* propagated by svnadmin hotcopy. So running both access methods at the same time, with anything other than read-only public access for the Apache service, gets nutty.
