1.7.0-alpha2 testsuite pysqlite complications with CentOS
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.
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.
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 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.
--
Josh
diff -Naru tree-old/subversion/tests/cmdline/svntest/__init__.py tree-new/subversion/tests/cmdline/svntest/__init__.py
--- tree-old/subversion/tests/cmdline/svntest/__init__.py 2011-07-01 19:37:42.0 +
+++ tree-new/subversion/tests/cmdline/svntest/__init__.py 2011-07-01 21:27:10.0 +
@@ -36,10 +36,13 @@
import sqlite3
except ImportError:
try:
-from pysqlite2 import dbapi2 as sqlite3
+import sqlite as sqlite3
except ImportError:
-sys.stderr.write('[SKIPPED] Python sqlite3 module required\n')
-sys.exit(0)
+try:
+ from pysqlite2 import dbapi2 as sqlite3
+except ImportError:
+ sys.stderr.write('[SKIPPED] Python sqlite3 module required\n')
+ sys.exit(0)
# don't export this name
del sys
[PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
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: SVN 1.7 - check out single file?
On 7/1/2011 1:14 PM, Andy Levy wrote: On Fri, Jul 1, 2011 at 13:10, Phil Pinkerton wrote: On 7/1/2011 11:38 AM, joe.floe...@sungard.com wrote: -Original Message- From: Andy Levy [mailto:andy.l...@gmail.com] Sent: Friday, July 01, 2011 10:22 AM To: Andy Levy; users@subversion.apache.org Subject: Re: SVN 1.7 - check out single file? On Fri, Jun 24, 2011 at 17:05, Stefan Sperlingwrote: 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. There may be more people who would like this feature than you think. Actually this ability is just what we are looking for. We are migrating off of SCCS and RCS to SVN. We organize our 9000 source files into two directories. We were disappointed that svn did not allow single file checkout. 90% of our work is maintenance involving 'work tickets' that affect only one or two files. So right now, in test, our checkouts run 4-10 minutes (depending on other server tasks and network traffic). This, as an optional ability, would be great for us. On the same note I have been involved with migrating some 200 VSS databases to Subversion, one of the big issues is the ability to checkout a single file, we default to using export in those cases as many checkouts , updates and commits are done via scripts. The other issue with regards to functionality of Subversion vs VSS is that many times VSS gets files from multiple locations in the database and puts them in the working directory. We find it difficult if not impossible to do the same with Subversion. In what ways could svn:externals be improved to do what you need? My memories of "sharing" in VSS are all nightmares. No doubt about VSS that is why I convinced the entire Enterprise that it was not the appropriate application for source code management and development. Just having the ability to checkout a single file via TortoiseSVN or the commandline would be a huge gain for us. I am trying to promote changing the development process but too many legacy applications still exist that have dependencies on VSS where developers are not able or even willing to change to optimize the utilization of Subversion. We have a hack in place to handle the worst offending application that was built around VSS.
Re: SVN 1.7 - check out single file?
On Fri, Jul 1, 2011 at 13:10, Phil Pinkerton wrote: > On 7/1/2011 11:38 AM, joe.floe...@sungard.com wrote: >> >> -Original Message- >> From: Andy Levy [mailto:andy.l...@gmail.com] >> Sent: Friday, July 01, 2011 10:22 AM >> To: Andy Levy; users@subversion.apache.org >> Subject: 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. >> >> >> >> There may be more people who would like this feature than you think. >> Actually this ability is just what we are looking for. We are migrating >> off of SCCS and RCS to SVN. We organize our 9000 source files into two >> directories. We were disappointed that svn did not allow single file >> checkout. 90% of our work is maintenance involving 'work tickets' that >> affect only one or two files. So right now, in test, our checkouts run >> 4-10 minutes (depending on other server tasks and network traffic). >> This, as an optional ability, would be great for us. >> >> >> >> >> > On the same note I have been involved with migrating some 200 VSS databases > to Subversion, one of the big issues is the ability to checkout a single > file, we default to using export in those cases as many checkouts , updates > and commits are done via scripts. > > The other issue with regards to functionality of Subversion vs VSS is that > many times VSS gets files from multiple locations in the database and puts > them in the working directory. We find it difficult if not impossible to do > the same with Subversion. In what ways could svn:externals be improved to do what you need? My memories of "sharing" in VSS are all nightmares.
Re: SVN 1.7 - check out single file?
On 7/1/2011 11:38 AM, joe.floe...@sungard.com wrote: -Original Message- From: Andy Levy [mailto:andy.l...@gmail.com] Sent: Friday, July 01, 2011 10:22 AM To: Andy Levy; users@subversion.apache.org Subject: 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. There may be more people who would like this feature than you think. Actually this ability is just what we are looking for. We are migrating off of SCCS and RCS to SVN. We organize our 9000 source files into two directories. We were disappointed that svn did not allow single file checkout. 90% of our work is maintenance involving 'work tickets' that affect only one or two files. So right now, in test, our checkouts run 4-10 minutes (depending on other server tasks and network traffic). This, as an optional ability, would be great for us. On the same note I have been involved with migrating some 200 VSS databases to Subversion, one of the big issues is the ability to checkout a single file, we default to using export in those cases as many checkouts , updates and commits are done via scripts. The other issue with regards to functionality of Subversion vs VSS is that many times VSS gets files from multiple locations in the database and puts them in the working directory. We find it difficult if not impossible to do the same with Subversion.
RE: SVN 1.7 - check out single file?
-Original Message- From: Andy Levy [mailto:andy.l...@gmail.com] Sent: Friday, July 01, 2011 10:22 AM To: Andy Levy; users@subversion.apache.org Subject: 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. There may be more people who would like this feature than you think. Actually this ability is just what we are looking for. We are migrating off of SCCS and RCS to SVN. We organize our 9000 source files into two directories. We were disappointed that svn did not allow single file checkout. 90% of our work is maintenance involving 'work tickets' that affect only one or two files. So right now, in test, our checkouts run 4-10 minutes (depending on other server tasks and network traffic). This, as an optional ability, would be great for us.
Re: Branching Questions
On 7/1/2011 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/ After getting the question clarified the customer was not using the word "lock" properly. We have an extensive ACL (one only for several hundred Repositories) and just about every access scenario down to the file level., so in this particular case there is no issue, as we are well versed in Apache and Subversion authz in combination with LDAP and the svn access file. thanks for you responses
Re: Branching Questions
On 7/1/2011 9:57 AM, Andy Levy wrote: Please stop top-posting. The convention on this mailing list is to bottom- or inline-post, and quote the relevant portions you're responding to. On Fri, Jul 1, 2011 at 09:43, Phil Pinkerton wrote: Interesting, Can you (or anyone else) provide a few scenario examples from your experience (not related to horses and besides those given in the svnbook.red-bean)? What are you looking for, exactly? If you need to restrict all access to a path, including read access, then you need to use Subversion's built-in path-based authorization or possibly some Apache configuration tweaks. The links you were given describe this very well - it's up to you to read& understand how they apply to your environment. If you need to restrict write access, you can use path-based authorization or a hook script. One script commonly used for this is svnperms.py svnperms.py requires more setup, but allows for wildcards and finer-grained control. If you're asking someone to show you a reference implementation, everyone's implementation of access control is a little different; it's best if you understand *how* it works and then how you can apply it to your environment. On 7/1/2011 8:11 AM, Tony Sweeney wrote: Sorry, that's a common British idiom which obviously doesn't travel. Racehorses vary in strength, speed, stamina and temperament; some race horses do better in "heavier going" (i.e. a softer, muddier track), some race faster on a dry course, and of course racecourses vary in length. So there's no single answer to "which is the best horse", as there are "horses for courses". Makes sense now? Which approach you take to (3) depends on the existing customer set up. There are a number of tradeoffs, so there's no single right answer. Tony. -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 12:45 To: Tony Sweeney Cc: Subversion User List Subject: Re: Branching Questions Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 I have reset Lanikai to use "bottom" reply. thanks for the reminder
Re: svn merge - get the last revision of a file(s)
Hi! Like I said before, I'm currently using the subclise plugin to manage all the svn interaction with the repository. As far as I know, I'm able to select the revisions which I want to apply but I'm not sure about the following aspect: - on revision 10, aaa.php has some changes - on revision 15, aaa.php has other changes Once on subclipse is not handy to select latest revision of a certain file (15, considering my example), is there any way to obtain that information. Thanks for the help, On Jul 1, 4:14 pm, Geoff Hoffman wrote: > Rui - > > I'm not sure I understand what you're asking. Maybe an example would help.
Re: Branching Questions
> 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/
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: Standards "Best Practice"
On Fri, Jul 1, 2011 at 08:47, Nico Kadel-Garcia wrote: > On Fri, Jul 1, 2011 at 8:27 AM, Andy Levy wrote: >> On Fri, Jul 1, 2011 at 07:55, Nico Kadel-Garcia wrote: >> >>> This is more likely to happen in virtualization due to limiting the >>> disk resources. Think hard about your back end disk storage. Let us >>> know if you use attached storage such as a NetApp or fibre channel, >>> I've got some notes on aligning those filesystems for virtualization, >>> which makes a huge performance improvement. >> >> I'd like to see those notes if I can. We're on a NetApp device right >> now but when we upgrade our environment later this year we'll be >> moving storage to an Equallogic device. We have had some Subversion >> performance issues with large checkouts using the NetApp device. The >> Equallogic appears to be better-tuned in general (we've had no trouble >> running a 100GB SQL Server DB off it) but every little bit helps. > > The big booby trap was the 4096 byte block alignment, as described at > http://www.citrix.com/site/resources/dynamic/partnerDocs/BestPracticesforFileSystemAlignmentinVirtualEnvironments.pdf. > This is awkward to configure fat installation time for virtualized > OS's, and it makes a huge performance difference. If you look up "4096 > byte block NetApp Nico Kadel-Garcia" on Google, you'll see my comments > on this for the last year or so. > > My old work accounts at Red Hat and NetApp are no longer active (I > ended that contract and started a new job.), so I don't have access to > the scripts I submitted on their support sites. Do you have Access to > Red Hat's knowledgebase? Some notes are at > https://www.redhat.com/archives/rhelv6-beta-list/2010-August/msg00069.html, > and I can dig around for a published copy of the tools. > 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.
Re: svn merge - get the last revision of a file(s)
Rui - I'm not sure I understand what you're asking. Maybe an example would help.
RE: Branching Questions
-Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 15:50 To: Andy Levy Cc: Tony Sweeney; Subversion User List Subject: Re: Branching Questions On 7/1/2011 9:57 AM, Andy Levy wrote: > Please stop top-posting. > I was simply following the responce format to my orignial email, I understand about bottom response, but thing change so I just followed what I recieved. Which was, in fact, my fault, as I thought I was replying only to Phil. (I would blame Outlook, which is what my employer provides, but a bad workman &c.). Tony. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
Re: Branching Questions
On 7/1/2011 9:57 AM, Andy Levy wrote: Please stop top-posting. The convention on this mailing list is to bottom- or inline-post, and quote the relevant portions you're responding to. On Fri, Jul 1, 2011 at 09:43, Phil Pinkerton wrote: Interesting, Can you (or anyone else) provide a few scenario examples from your experience (not related to horses and besides those given in the svnbook.red-bean)? What are you looking for, exactly? If you need to restrict all access to a path, including read access, then you need to use Subversion's built-in path-based authorization or possibly some Apache configuration tweaks. The links you were given describe this very well - it's up to you to read& understand how they apply to your environment. If you need to restrict write access, you can use path-based authorization or a hook script. One script commonly used for this is svnperms.py svnperms.py requires more setup, but allows for wildcards and finer-grained control. If you're asking someone to show you a reference implementation, everyone's implementation of access control is a little different; it's best if you understand *how* it works and then how you can apply it to your environment. On 7/1/2011 8:11 AM, Tony Sweeney wrote: Sorry, that's a common British idiom which obviously doesn't travel. Racehorses vary in strength, speed, stamina and temperament; some race horses do better in "heavier going" (i.e. a softer, muddier track), some race faster on a dry course, and of course racecourses vary in length. So there's no single answer to "which is the best horse", as there are "horses for courses". Makes sense now? Which approach you take to (3) depends on the existing customer set up. There are a number of tradeoffs, so there's no single right answer. Tony. -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 12:45 To: Tony Sweeney Cc: Subversion User List Subject: Re: Branching Questions Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 I was simply following the responce format to my orignial email, I understand about bottom response, but thing change so I just followed what I recieved.
Re: Branching Questions
I suppose the question was a bit ambiguous, I see your point I'll ask for clarity. On 7/1/2011 9:57 AM, Andy Levy wrote: Please stop top-posting. The convention on this mailing list is to bottom- or inline-post, and quote the relevant portions you're responding to. On Fri, Jul 1, 2011 at 09:43, Phil Pinkerton wrote: Interesting, Can you (or anyone else) provide a few scenario examples from your experience (not related to horses and besides those given in the svnbook.red-bean)? What are you looking for, exactly? If you need to restrict all access to a path, including read access, then you need to use Subversion's built-in path-based authorization or possibly some Apache configuration tweaks. The links you were given describe this very well - it's up to you to read& understand how they apply to your environment. If you need to restrict write access, you can use path-based authorization or a hook script. One script commonly used for this is svnperms.py svnperms.py requires more setup, but allows for wildcards and finer-grained control. If you're asking someone to show you a reference implementation, everyone's implementation of access control is a little different; it's best if you understand *how* it works and then how you can apply it to your environment. On 7/1/2011 8:11 AM, Tony Sweeney wrote: Sorry, that's a common British idiom which obviously doesn't travel. Racehorses vary in strength, speed, stamina and temperament; some race horses do better in "heavier going" (i.e. a softer, muddier track), some race faster on a dry course, and of course racecourses vary in length. So there's no single answer to "which is the best horse", as there are "horses for courses". Makes sense now? Which approach you take to (3) depends on the existing customer set up. There are a number of tradeoffs, so there's no single right answer. Tony. -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 12:45 To: Tony Sweeney Cc: Subversion User List Subject: Re: Branching Questions Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
svn merge - get the last revision of a file(s)
Hi there! I'm trying to merge a branch into other one, without reintegrating the all branch. Once there many files with several revisions, I would like if is possible to get the last revision of all changed files/ directories in order to avoid "intermediate" merges. I'm currently using the subclipse plugin but I'm comfortable enough to use the svn cli. Thanks in advance for the help, Best regards!
Re: Branching Questions
Please stop top-posting. The convention on this mailing list is to bottom- or inline-post, and quote the relevant portions you're responding to. On Fri, Jul 1, 2011 at 09:43, Phil Pinkerton wrote: > Interesting, > > Can you (or anyone else) provide a few scenario examples from your > experience (not related to horses and besides those given in the > svnbook.red-bean)? What are you looking for, exactly? If you need to restrict all access to a path, including read access, then you need to use Subversion's built-in path-based authorization or possibly some Apache configuration tweaks. The links you were given describe this very well - it's up to you to read & understand how they apply to your environment. If you need to restrict write access, you can use path-based authorization or a hook script. One script commonly used for this is svnperms.py svnperms.py requires more setup, but allows for wildcards and finer-grained control. If you're asking someone to show you a reference implementation, everyone's implementation of access control is a little different; it's best if you understand *how* it works and then how you can apply it to your environment. > On 7/1/2011 8:11 AM, Tony Sweeney wrote: >> >> Sorry, that's a common British idiom which obviously doesn't travel. >> Racehorses vary in strength, speed, stamina and temperament; some race >> horses do better in "heavier going" (i.e. a softer, muddier track), some >> race faster on a dry course, and of course racecourses vary in length. >> So there's no single answer to "which is the best horse", as there are >> "horses for courses". Makes sense now? Which approach you take to (3) >> depends on the existing customer set up. There are a number of >> tradeoffs, so there's no single right answer. >> >> Tony. >> >> -Original Message- >> From: Phil Pinkerton [mailto:pcpinker...@gmail.com] >> Sent: 01 July 2011 12:45 >> To: Tony Sweeney >> Cc: Subversion User List >> Subject: Re: Branching Questions >> >> Thanks for the quick response. >> >> However I have no clue what you mean by Horses for courses. >> >> and I certainly cannot reply to my clients question with such an answer. >> >> On 7/1/2011 7:03 AM, Tony Sweeney wrote: >>> >>> -Original Message- >>> From: Phil Pinkerton [mailto:pcpinker...@gmail.com] >>> Sent: 01 July 2011 11:58 >>> To: Subversion User List >>> Subject: Branching Questions >>> >>> >>> 1. We are creating branch out of previous branch, if we want to delete >>> a old branch or archive it how it will impact the current branch ? >>> >>> It won't >>> >>> 2. There is no limit on number of branches you can create, is this >>> true ? >>> >>> Effectively. >>> >>> 3. What is the best way to lock the Trunk so only certain users can >>> access it, using Hook Script or using admin tool? >>> >>> Horses for courses. >>> >>> >>> Phil >>> >>> >>> __ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> __ >>> >>> - >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: >>> 06/30/11 >>> >> __ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> __ >> >> - >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 >> >
Re: Branching Questions
Interesting, Can you (or anyone else) provide a few scenario examples from your experience (not related to horses and besides those given in the svnbook.red-bean)? On 7/1/2011 8:11 AM, Tony Sweeney wrote: Sorry, that's a common British idiom which obviously doesn't travel. Racehorses vary in strength, speed, stamina and temperament; some race horses do better in "heavier going" (i.e. a softer, muddier track), some race faster on a dry course, and of course racecourses vary in length. So there's no single answer to "which is the best horse", as there are "horses for courses". Makes sense now? Which approach you take to (3) depends on the existing customer set up. There are a number of tradeoffs, so there's no single right answer. Tony. -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 12:45 To: Tony Sweeney Cc: Subversion User List Subject: Re: Branching Questions Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
Re: branch question
On Thu, Jun 23, 2011 at 5:01 PM, Geoff Hoffman wrote: > What I mean by that is, it may have ramifications down the road for *your > workflow* (I can't think of any obvious examples), but svn copy [from] [to] > works on any path, local or remote, as you would expect. > > On Thu, Jun 23, 2011 at 1:57 PM, Geoff Hoffman > wrote: >> >> Not in any general sense, no. >> >> On Thu, Jun 23, 2011 at 1:27 PM, Phil Pinkerton >> wrote: >>> >>> Any issues with creating a branch from a branch? no trunk and no merge >>> back to first branch ? >>> >>> >>> Phil Oh, lord, top-posting. I just ran into a long rant about this on another list. One subtle booby trap that I *just* found out about, if you do something like this to internally "branch" your work and then delete the original material as part of a "how do I move this material to a better location in the source tree", rather than doing an "svn move", you break git-svn history of that internal "branch". Personally, I'm not put out by it: I see git-svn as a friendly portal for distributed work, not a primary access to subversion repository history, but it was profoundly irksome to people who believe that sacrosanct history is one of the whole points of a repository history, and I can understand that view.
Re: Standards "Best Practice"
On Fri, Jul 1, 2011 at 8:27 AM, Andy Levy wrote: > On Fri, Jul 1, 2011 at 07:55, Nico Kadel-Garcia wrote: > >> This is more likely to happen in virtualization due to limiting the >> disk resources. Think hard about your back end disk storage. Let us >> know if you use attached storage such as a NetApp or fibre channel, >> I've got some notes on aligning those filesystems for virtualization, >> which makes a huge performance improvement. > > I'd like to see those notes if I can. We're on a NetApp device right > now but when we upgrade our environment later this year we'll be > moving storage to an Equallogic device. We have had some Subversion > performance issues with large checkouts using the NetApp device. The > Equallogic appears to be better-tuned in general (we've had no trouble > running a 100GB SQL Server DB off it) but every little bit helps. The big booby trap was the 4096 byte block alignment, as described at http://www.citrix.com/site/resources/dynamic/partnerDocs/BestPracticesforFileSystemAlignmentinVirtualEnvironments.pdf. This is awkward to configure fat installation time for virtualized OS's, and it makes a huge performance difference. If you look up "4096 byte block NetApp Nico Kadel-Garcia" on Google, you'll see my comments on this for the last year or so. My old work accounts at Red Hat and NetApp are no longer active (I ended that contract and started a new job.), so I don't have access to the scripts I submitted on their support sites. Do you have Access to Red Hat's knowledgebase? Some notes are at https://www.redhat.com/archives/rhelv6-beta-list/2010-August/msg00069.html, and I can dig around for a published copy of the tools.
Re: Standards "Best Practice"
On Fri, Jul 1, 2011 at 07:55, Nico Kadel-Garcia wrote: > This is more likely to happen in virtualization due to limiting the > disk resources. Think hard about your back end disk storage. Let us > know if you use attached storage such as a NetApp or fibre channel, > I've got some notes on aligning those filesystems for virtualization, > which makes a huge performance improvement. I'd like to see those notes if I can. We're on a NetApp device right now but when we upgrade our environment later this year we'll be moving storage to an Equallogic device. We have had some Subversion performance issues with large checkouts using the NetApp device. The Equallogic appears to be better-tuned in general (we've had no trouble running a 100GB SQL Server DB off it) but every little bit helps.
RE: Branching Questions
Sorry, that's a common British idiom which obviously doesn't travel. Racehorses vary in strength, speed, stamina and temperament; some race horses do better in "heavier going" (i.e. a softer, muddier track), some race faster on a dry course, and of course racecourses vary in length. So there's no single answer to "which is the best horse", as there are "horses for courses". Makes sense now? Which approach you take to (3) depends on the existing customer set up. There are a number of tradeoffs, so there's no single right answer. Tony. -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 12:45 To: Tony Sweeney Cc: Subversion User List Subject: Re: Branching Questions Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: > > > -Original Message- > From: Phil Pinkerton [mailto:pcpinker...@gmail.com] > Sent: 01 July 2011 11:58 > To: Subversion User List > Subject: Branching Questions > > > 1. We are creating branch out of previous branch, if we want to delete > a old branch or archive it how it will impact the current branch ? > > It won't > > 2. There is no limit on number of branches you can create, is this > true ? > > Effectively. > > 3. What is the best way to lock the Trunk so only certain users can > access it, using Hook Script or using admin tool? > > Horses for courses. > > > Phil > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > > - > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: > 06/30/11 > __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
Re: Branching Questions
Guten Tag Phil Pinkerton, am Freitag, 1. Juli 2011 um 12:58 schrieben Sie: > 3. What is the best way to lock the Trunk so only certain users can > access it, using Hook Script or using admin tool? This depends on what you mean with locking. Do you mean the subversion way as in [1] or access rights? In the latter [2] and [3] for path bases authorization should help you. [1]: http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html [2]: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general [3]: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Standards "Best Practice"
On Fri, Jul 1, 2011 at 6:45 AM, Phil Pinkerton wrote: > Are there recommended standards with regards to Repository size, number of > users per Repository, what type of data is contained in a Repository? I've seen no published standards. It's relatively sensitive to layout: A thousand users who aren't very active or are almost entirely read-only might use a central server for a small repo. A bulky repo that takes over an hour to check out due to thousands of individual files and a tendency to have lots and lots and lots of auto-generated branches, and people refuse to pick and choose their branches for download, is a separate problem. > Any experience with performance issues in regards to running Subversion on > VMware vs a Blade Server ? I've stuck with virtualization for testing repos only. Disk I/O tends to be a serious bottleneck. The worst drawback I've had is when someone kept insisting, insisting that it was fine to keep the disks at 90% full because it was "stable" and "we'd know if something would add to it". But the filesystem would *fragment* as data churned on there, and I had to make charts to convince him to let me back up and rebuild the filesystem, then we went back around over that fight six months later. (It was storing a huge web proxy cache: the data churn was ridiculous.) This is more likely to happen in virtualization due to limiting the disk resources. Think hard about your back end disk storage. Let us know if you use attached storage such as a NetApp or fibre channel, I've got some notes on aligning those filesystems for virtualization, which makes a huge performance improvement.
Re: Branching Questions
Thanks for the quick response. However I have no clue what you mean by Horses for courses. and I certainly cannot reply to my clients question with such an answer. On 7/1/2011 7:03 AM, Tony Sweeney wrote: -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
RE: Branching Questions
-Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: 01 July 2011 11:58 To: Subversion User List Subject: Branching Questions 1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? It won't 2. There is no limit on number of branches you can create, is this true ? Effectively. 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Horses for courses. Phil __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11
Branching Questions
1. We are creating branch out of previous branch, if we want to delete a old branch or archive it how it will impact the current branch ? 2. There is no limit on number of branches you can create, is this true ? 3. What is the best way to lock the Trunk so only certain users can access it, using Hook Script or using admin tool? Phil
Standards "Best Practice"
Are there recommended standards with regards to Repository size, number of users per Repository, what type of data is contained in a Repository? Any experience with performance issues in regards to running Subversion on VMware vs a Blade Server ? Phil
Re: how to get a list of unmerged revisions?
Hi,
I have written a python (pysvn) script for myself to detect unmerged revs.
Maybe its somehow helpful to you.
I use it like this:
python svn_check_merges branches/ /trunk
---
#!/usr/bin/env python
# -*- python -*- coding: iso-8859-1 -*-
# $Id$
"""
Check if we have all revisison merged in given svn tree, and notifying
the the users, who have still some things to do.
call with:
svn_check_args
where svnfrom and svnto are relative pathes to svnroot
(c) Jan Stürtz j...@contact.de
"""
import optparse
import pysvn
import sys
import time
SVNROOT = "http://svn.acme.org/svn/src";
def get_mergedrevs(mergedfrom, path):
"""get svn:merginfo Property for a certain path,
and get all revs from there as a set"""
svnwc = pysvn.Client()
props = svnwc.propget("svn:mergeinfo", path)
# Mergeinfo is only one key/val pair, convert to a usable dict
mergeinfo = dict([(tuple(pathitem.split(":")))
for pathitem in props[path].split("\n")])
result = []
if mergedfrom.startswith(SVNROOT):
mergedfrom = mergedfrom[len(SVNROOT):]
for key, val in mergeinfo.items():
if key == mergedfrom:
revs = [(rev.strip().rstrip("*")) for rev in val.split(",")]
for rev in revs:
if rev.find("-") < 0:
result.append(int(rev))
else:
revs = [int(r) for r in rev.split("-")]
# increase by one due to logic of range
revs[1] += 1
result.extend(range(*(tuple(revs
break
return set(result)
def get_branchrevs(branch):
"""get all revs from the branch"""
svnwc = pysvn.Client()
logs = svnwc.log(branch)
result = dict([(log.revision.number, log) for log in logs])
return result
def log2str(log):
msg = ""
author = ""
if "message" in log and log.message:
msg = log.message[0:log.message.find("\n")]
if "author" in log and log.author:
author = log.author
return ("%(rev)6s | "
"%(date)10s | "
"%(author)-6s | "
"%(msg)s" %
{"rev": log.revision.number,
"date": time.strftime("%d.%m.%Y", time.localtime(log.date)),
"msg": msg,
"author": author})
def _main():
parser = optparse.OptionParser(usage=__doc__)
parser.add_option(
"--svnroot", default=SVNROOT,
help="Use a different svnroot (default: %s)" % SVNROOT)
(options, args) = parser.parse_args()
if len(args) >= 2:
svnfrom = SVNROOT + args[0]
svnto = SVNROOT + args[1]
else:
parser.error("Missing arguments")
mergedrevs = get_mergedrevs(svnfrom, svnto)
branchrevs = get_branchrevs(svnfrom)
missingrevs = list(set(branchrevs.keys()).difference(mergedrevs))
missingrevs.sort()
per_author = {}
for rev in missingrevs:
log = branchrevs[rev]
print log2str(log).encode(sys.getdefaultencoding(), "replace")
if "author" in log:
if log.author in per_author:
per_author[log.author].append(log)
else:
per_author[log.author] = [log]
if missingrevs:
print "Nonmerged revisions: %d" % len(missingrevs)
if __name__ == "__main__":
_main()
- Jan
Mit freundlichen Grüßen
Jan Stürtz
Software Architect
--
CONTACT Software GmbH Tel.: +49 (421) 201 53-0
Wiener Straße 1-3 Fax:+49 (421) 201 53-41
28359 Bremen - Germany http://www.contact.de/
Sitz der Gesellschaft: Bremen
Geschäftsführer: Karl Heinz Zachries, Ralf Holtgrefe
Eingetragen im Handelsregister des Amtsgerichts Bremen unter HRB 13215
Am 20.06.2011 00:23, schrieb B Smith-Mannschott:
> I've got a trunk and a maintenance branch. I periodically merge
> changes from the maintenance branch to trunk. Merge tracking is a
> help here.
>
> Commits on the maintenance branch begin with an ID identifying the
> issue, backlog item or user story. When I merge changes to trunk, I'd
> like to merge those belonging to the same ID together, but I don't
> want to mix different IDs in the same merge.
>
> To do this, I explicitly name the revisions I want to merge on the command
> line.
>
> Now, how do I get Subversion to tell me which revisions of
> have not been merged to ?
>
> What I've been doing is either (1) firing up TortoiseSVN, which shows
> already merged revisions in grey when you start a log viewer from the
> merge dialog box or (2) actually doing the merge and then meditating
> over the diff of the svn:merge-info property before reverting the
> merge again and doing it properly.
>
> Both of these approaches are awkward in the extreme. Surely I'm
> overlooking something obvious.
>
> // Ben
signature.asc
Description: OpenPGP digital signature
