Re: Using * in AuthzSVNAccessFile file
On Thu, May 20, 2010 at 10:48 PM, vishwajeet singh wrote: > > > On Fri, May 21, 2010 at 2:16 AM, Prakash Velayutham > wrote: >> >> Hi, >> >> Is it possible to use '*' in the path portion of a AuthzSVNAccessFile. >> >> Like >> >> [repo:/folder1/*/*/bc] >> @group1 = rw >> @group2 = r >> @admin = rw >> >> Would this work? In the redbook, it only talks about using '*' for the >> user/group portion, not the path. > > > Not it would not work. FYI, there is an (open) enhancement request for this: http://subversion.tigris.org/issues/show_bug.cgi?id=2662 - authz with wildcards It seems that several patches were created for this, but for some reason they were never committed. Maybe someone with interest in this issue should try to take a look at those patches again, bring them up on the dev list for review, ... Cheers, -- Johan
Using subversion (or something else?)
I am trying to decide, or at least get information to help me decide, whether subversion or "something else" would be suitable for us. Let me explain the situation. We use a product which we customise and add features to, both of which mean changing the source. Sometimes these changes also get accepted by the vendor and are included in the next release. So when we get a new release we get a new bundle of source files and so forth (in some format which I don't know offhand, but probably isn't important to this anyway), and we then have to manually merge the changes we have made to the last version into the new version, some of which might be changes we already have. I think one way of thinking about it is that our changes are a series of patches, some of which are accepted upstream and some not (this is what makes me wonder whether something other than subversion might be better for us, but that might be just my brain making a connection between the word "patch" and systems that I know use this kind of patching concept, such as darcs). Maybe there is an alternative way of thinking about the situation which means that subversion, which I am more at home with, would be suited. So the first question is, do you think subversion is suitable in this case, and if not is there something "better" (in the sense it will be easier for us to use) that you can recommend? So the first question is, do you think subversion is suitable in this case, and if not is there something "better" (in the sense it will be easier for us to use) that you can recommend? Secondly, if subversion is suitable, what's the best way to use it in this situation (regarding branching, releasing, etc.)? I worked somewhere with this kind of situation before (changing and customising vendor code, with new vendor releases being introduced from time to time), and we basically used branches for each new vendor, and internal, release. Where I am now, we have a very short internal release cycle, along the lines of "code it, ship it!" (we effectively work directly on the live system, which I am not in favour of, but we do need that quick turnaround from code-change to production system). At the other place we had a script that did a lot of the merging between the production branch, where bug fixes would be implemented, and the "new features" branch where we would be working. Obviously I don't have that script now, but is there anything around that can do that kind of merging, if I managed to convince people to adopt that kind of way or working? Or is there some better way of working in this situation? Okay, so "better" is somewhat subjective, but I am open to ideas so don't be afraid to throw them into the middle. Thanks in advance for your suggestions.
Re: Using subversion (or something else?)
On May 21, 2010, at 04:32, Gary . wrote: > We use a product which we > customise and add features to, both of which mean changing the > source. Sometimes these changes also get accepted by the vendor > and are included in the next release. The Vendor Branches chapter in the book addresses how you can handle this in Subversion. http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html If the source code is coming out of a Subversion repository on their end, and you have at least read access to it, then it can be even easier (you can just "svn merge" their latest changes from their repository to yours).
Re: Using subversion (or something else?)
On Fri, May 21, 2010 at 04:58:02AM -0500, Ryan Schmidt wrote: > > On May 21, 2010, at 04:32, Gary . wrote: > > > We use a product which we > > customise and add features to, both of which mean changing the > > source. Sometimes these changes also get accepted by the vendor > > and are included in the next release. > > The Vendor Branches chapter in the book addresses how you can handle this in > Subversion. > > http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html > > If the source code is coming out of a Subversion repository on their > end, and you have at least read access to it, then it can be even > easier (you can just "svn merge" their latest changes from their > repository to yours). > Also, Subversion 1.7 will have a 'patch' subcommand, which in addition to patching file content will automatically add new files and directories the patch creates and automatically remove files and directories left empty after patching. So in 1.7, you will be able to update a vendor branch like this: tar -zxf vendor-release-1.0.tar.gz tar -zxf vendor-release-2.0.tar.gz diff -urN vendor-release-1.0 vendor-release-2.0 > /tmp/vendor.patch svn co http://svn.example.com/repos/branches/vendor cd vendor svn patch /tmp/vendor.patch svn commit -m "update to 2.0" Stefan
Re: Using subversion (or something else?)
On Fri, May 21, 2010 at 11:58 AM, Ryan Schmidt wrote: > On May 21, 2010, at 04:32, Gary . wrote: > >> We use a product which we >> customise and add features to, both of which mean changing the >> source. Sometimes these changes also get accepted by the vendor >> and are included in the next release. > > The Vendor Branches chapter in the book addresses how you can handle this in > Subversion. Oh! How embarrassing. I'm just reading that document as it happens, but hadn't got that far through it yet :) Thanks for the hint!
Re: Maxsize of Properties
Von: Ryan Schmidt An: Bettual Richter Kopie: users@subversion.apache.org Datum: 20.05.2010 13:09 Betreff: Re: Maxsize of Properties On May 20, 2010, at 05:40, Bettual Richter wrote: > does anyone know if there is some kind of maxsize for revision properties ? >>I'm not sure. > I'd like to set long revision properties on a repository. >>How large? I'm not really sure how large the properties are finally going to be but lets say like 10 000 000 charaters would be quite desirable.
Re: Using subversion (or something else?)
On Fri, May 21, 2010 at 11:58 AM, Ryan Schmidt wrote: > The Vendor Branches chapter in the book addresses how you can handle this in > Subversion. > > http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html Hrmph. I couldn't get the example in the doc to work whentrying it with a toy example: j...@work ~/work/svntest $ svn import ./foobar file:///mnt/h/svn/GDJ/foobar -m "initial drop" svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///mnt/h/svn/GDJ/foobar' where: j...@work ~/work/svntest $ ls -la /mnt/h/svn total 0 drwxr-xr-x+ 1 jg Domänen-Benutzer 0 May 21 14:46 . drwx--+ 1 Administratoren Domänen-Benutzer 0 May 21 14:40 .. drwxr-xr-x+ 1 jg Domänen-Benutzer 0 May 21 12:56 jg Accessing the jg project is fine: j...@work ~/work/svntest $ svn list file:///mnt/h/svn/jg .bashrc .bashrc.d/ .emacs.d/ .emacs.el .gnus/ .gnus.el Of course, GDJ doesn't exist. Am I supposed to create this first? Apparently so, although the documentation doesn't mention this: j...@work ~/work/svntest $ svnadmin create /mnt/h/svn/GDJ j...@work ~/work/svntest $ svn import /home/jg/work/svntest/foobar file:///mnt/h/svn/GDJ/foobar -m "initial drop" Adding ...(many files) ... Committed revision 1. But I still get a very similar error when I try to to tag the stuff. The tagging of the "vendor data" went okay, but, after creating my project structure: $ svn import . file:///mnt/h/svn/myproject -m "create project structure" Adding trunk Adding branches Adding tags Committed revision 1. when trying to copy the "vendor data": j...@work ~/work/svntest $ svn copy file:///mnt/h/svn/GDJ/foobar/0.1 \ file:///mnt/h/svn/myproject/trunk/foobar \ -m "bring foobar-0.1 into driver project" svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///mnt/h/svn' Huh? "Unable to open repository 'file:///mnt/h/svn'"? To which URL is it even referring?
Re: Using subversion (or something else?)
On 5/21/2010 8:52 AM, Gary . wrote: On Fri, May 21, 2010 at 11:58 AM, Ryan Schmidt wrote: The Vendor Branches chapter in the book addresses how you can handle this in Subversion. http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html Hrmph. I couldn't get the example in the doc to work whentrying it with a toy example: j...@work ~/work/svntest $ svn import ./foobar file:///mnt/h/svn/GDJ/foobar -m "initial drop" svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///mnt/h/svn/GDJ/foobar' where: j...@work ~/work/svntest $ ls -la /mnt/h/svn total 0 drwxr-xr-x+ 1 jg Domänen-Benutzer 0 May 21 14:46 . drwx--+ 1 Administratoren Domänen-Benutzer 0 May 21 14:40 .. drwxr-xr-x+ 1 jg Domänen-Benutzer 0 May 21 12:56 jg Yes, you can only import into an existing parent. Accessing the jg project is fine: j...@work ~/work/svntest $ svn list file:///mnt/h/svn/jg .bashrc .bashrc.d/ .emacs.d/ .emacs.el .gnus/ .gnus.el Which has nothing to do with the location you tried to use in the failing import. Of course, GDJ doesn't exist. Am I supposed to create this first? Apparently so, although the documentation doesn't mention this: j...@work ~/work/svntest $ svnadmin create /mnt/h/svn/GDJ Yes, the repository has to exist before you can use it. j...@work ~/work/svntest $ svn import /home/jg/work/svntest/foobar file:///mnt/h/svn/GDJ/foobar -m "initial drop" Adding ...(many files) ... Committed revision 1. But I still get a very similar error when I try to to tag the stuff. The tagging of the "vendor data" went okay, but, after creating my project structure: $ svn import . file:///mnt/h/svn/myproject -m "create project structure" Adding trunk Adding branches Adding tags Committed revision 1. when trying to copy the "vendor data": j...@work ~/work/svntest $ svn copy file:///mnt/h/svn/GDJ/foobar/0.1 \ file:///mnt/h/svn/myproject/trunk/foobar \ -m "bring foobar-0.1 into driver project" svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///mnt/h/svn' Huh? "Unable to open repository 'file:///mnt/h/svn'"? To which URL is it even referring? You can only svn copy with url's pointing to within the same repository. Or you can do it locally in a checked out working copy and commit it back. And is that file:///mnt/h/svn/GDJ/foobar/0.1 supposed to refer to a revision or is that a subdirectory you imported there? -- Les Mikesell lesmikes...@gmail.com
Re: Strange Error: svn: REPORT of '/svn/!svn/vcc/default': 200 OK (Repository URL)
It turns out this was an error on google's part. The problem was promptly fixed and here is what they had to say. " A bug recently caused some minor corruption in our datastore, causing 0.0003% of the files in our Subversion repositories to be unavailable. Unfortunately that included a few files from the trunk of the plsnpairs project. I've repaired the Bigtable and you should now be able to check out your project. Sorry for the inconvenience! "
Re: Maxsize of Properties
On May 21, 2010, at 06:39, Bettual Richter wrote: > Ryan Schmidt wrote: > >> On May 20, 2010, at 05:40, Bettual Richter wrote: >> >>> does anyone know if there is some kind of maxsize for revision properties >>> ? >> >> I'm not sure. >> >>> I'd like to set long revision properties on a repository. >> >> How large? > > I'm not really sure how large the properties are finally going to be > but lets say like 10 000 000 charaters would be quite desirable. Based on the error message "413 Request Entity Too Large", I'm guessing that's too large. When you're serving your repository via Apache, Subversion properties are implemented as WebDAV properties, I think. I found a reference [1] that says the WebDAV spec doesn't limit the size of properties, but that some implementations might. I guess maybe Apache and/or Subversion do impose a limit of some kind. Properties are designed for short strings, like the name of the author, the date and time, the log message. It therefore wouldn't surprise me to find out that this infrastructure is not prepared to accept a property with 10MB of data. If I'm right about Subversion properties being implemented as WebDAV properties, then you might have success bypassing WebDAV, i.e. using svnserve. Or that might fail too. I haven't tried. [1] http://books.google.com/books?id=LN6PRtgiwNgC&pg=PA164&lpg=PA164&dq=maximum+size+of+webdav+property&source=bl&ots=RzC0RsrP0A&sig=FeEp0d-X62pSLfvpfQf3He2yX3k&hl=en&ei=9nL2S6KFBIOUMdCPkIQI&sa=X&oi=book_result&ct=result&resnum=10&ved=0CDkQ6AEwCQ
RE: How to speed up subversion
Hi, > -Original Message- > From: Jeremy Conlin [mailto:jlcon...@gmail.com] > Sent: Wednesday, April 21, 2010 5:48 PM > To: users@subversion.apache.org > Subject: How to speed up subversion > > I have a working copy/respository with many files that are several > hundred MB each. Whenever I try to check the status of my working > copy or do a commit, it can take a long time (~1 min) before I get a > response. I don't have any externals and the number of total files in > my repository is ~100. Has anyone else experienced this or knows how > to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. I guess the speed of your hard disk is the issue. Commit and status both check if the files on the local hard drive have changed since the last update. They do this by comparing the originals in the .svn dirs to the files you are working on. When you have a lot of large files, that can take quite a long time (100 MB times 100 files are 10 GB that have to be read, twice!) I hope this points you in the right direction... Cheers, Ulli Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: Maxsize of Properties
On Fri, May 21, 2010 at 6:39 AM, Bettual Richter < bettual.richter_ext...@ppi.de> wrote: > > > Von: Ryan Schmidt An: Bettual Richter < > bettual.richter_ext...@ppi.de> Kopie: users@subversion.apache.org Datum: > 20.05.2010 > 13:09 Betreff: Re: Maxsize of Properties > -- > > > > On May 20, 2010, at 05:40, Bettual Richter wrote: > > > does anyone know if there is some kind of maxsize for revision > properties ? > > >>I'm not sure. > > > I'd like to set long revision properties on a repository. > > >>How large? > > I'm not really sure how large the properties are finally going to be > but lets say like 10 000 000 charaters would be quite desirable. Out of curiosity, why are you trying to use a 10MB property? Could you better store the data as a versioned file, rather than a versioned property? -Hyrum
Re: How to speed up subversion
On Fri, May 21, 2010 at 9:39 AM, wrote: > Hi, > > > -Original Message- > > From: Jeremy Conlin [mailto:jlcon...@gmail.com] > > Sent: Wednesday, April 21, 2010 5:48 PM > > To: users@subversion.apache.org > > Subject: How to speed up subversion > > > > I have a working copy/respository with many files that are several > > hundred MB each. Whenever I try to check the status of my working > > copy or do a commit, it can take a long time (~1 min) before I get a > > response. I don't have any externals and the number of total files in > > my repository is ~100. Has anyone else experienced this or knows how > > to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. > > I guess the speed of your hard disk is the issue. > > Commit and status both check if the files on the local hard drive have > changed since the last update. They do this by comparing the originals > in the .svn dirs to the files you are working on. When you have a lot of > large files, that can take quite a long time (100 MB times 100 files are > 10 GB that have to be read, twice!) > > I hope this points you in the right direction... > Actually, Subversion is a bit more intelligent about it, attempting to use modification times and sizes, before doing a byte-by-byte comparison. -Hyrum
RE: 1.6.11 on Vista
The only installation I had was the 1.6.6 server, the 1.6.11 install overlayed it. I did a find for svn.exe and there was no other installation. The only other subversion related software I have is TortoiseSVN, subclipse, & PySVN Roger -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Thursday, May 20, 2010 11:30 AM To: Talkov, Roger Cc: users@subversion.apache.org Subject: Re: 1.6.11 on Vista On Thu, May 20, 2010 at 2:26 PM, Talkov, Roger wrote: > I installed the Collabnet subversion server 1.6.11 on windows Vista and got > the error below when I typed "svn -version" > I had previously had 1.6.6 of the server which didn't have this problem Check your PATH. Sounds like you have more than one version installed and are getting DLL mismatches. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: 1.6.11 on Vista
Perhaps the server was running and the DLL could not be replaced by the installer? The error you are getting is that a newer client is loading an older DLL that does not have the symbol for the function installed. On Fri, May 21, 2010 at 11:43 AM, Talkov, Roger wrote: > The only installation I had was the 1.6.6 server, the 1.6.11 install > overlayed it. > I did a find for svn.exe and there was no other installation. > The only other subversion related software I have is TortoiseSVN, subclipse, > & PySVN > > Roger > > -Original Message- > From: Mark Phippard [mailto:markp...@gmail.com] > Sent: Thursday, May 20, 2010 11:30 AM > To: Talkov, Roger > Cc: users@subversion.apache.org > Subject: Re: 1.6.11 on Vista > > On Thu, May 20, 2010 at 2:26 PM, Talkov, Roger wrote: >> I installed the Collabnet subversion server 1.6.11 on windows Vista and got >> the error below when I typed "svn -version" >> I had previously had 1.6.6 of the server which didn't have this problem > > Check your PATH. Sounds like you have more than one version installed > and are getting DLL mismatches. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ > -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: 1.6.11 on Vista
I did shutdown the server , but it may have been after the install. I'll try it again with the server shutdown before the install Thanks, Roger -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Friday, May 21, 2010 8:45 AM To: Talkov, Roger Cc: users@subversion.apache.org Subject: Re: 1.6.11 on Vista Perhaps the server was running and the DLL could not be replaced by the installer? The error you are getting is that a newer client is loading an older DLL that does not have the symbol for the function installed. On Fri, May 21, 2010 at 11:43 AM, Talkov, Roger wrote: > The only installation I had was the 1.6.6 server, the 1.6.11 install > overlayed it. > I did a find for svn.exe and there was no other installation. > The only other subversion related software I have is TortoiseSVN, subclipse, > & PySVN > > Roger > > -Original Message- > From: Mark Phippard [mailto:markp...@gmail.com] > Sent: Thursday, May 20, 2010 11:30 AM > To: Talkov, Roger > Cc: users@subversion.apache.org > Subject: Re: 1.6.11 on Vista > > On Thu, May 20, 2010 at 2:26 PM, Talkov, Roger wrote: >> I installed the Collabnet subversion server 1.6.11 on windows Vista and got >> the error below when I typed "svn -version" >> I had previously had 1.6.6 of the server which didn't have this problem > > Check your PATH. Sounds like you have more than one version installed > and are getting DLL mismatches. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ > -- Thanks Mark Phippard http://markphip.blogspot.com/
repository sizes in different versions?
I have an old repository that I think was started with a 1.4.x version of subversion, then updated in several stages to 1.6.5 without doing any changes to the repo format. Du says this repository is taking about 38 gigs of disk space. I've recently duplicated this repository using snvsync from a system running 1.6.6, copying approximately 120,000 revisions. Du says this repository uses 1.9 gigs of disk space. Is that reasonable - or at least possible? Does it mean I should do something to compact the original copy? -- Les Mikesell lesmikes...@gmail.com
Re: repository sizes in different versions?
On May 21, 2010, at 13:44, Les Mikesell wrote: > I have an old repository that I think was started with a 1.4.x version of > subversion, then updated in several stages to 1.6.5 without doing any changes > to the repo format. Du says this repository is taking about 38 gigs of disk > space. I've recently duplicated this repository using snvsync from a system > running 1.6.6, copying approximately 120,000 revisions. Du says this > repository uses 1.9 gigs of disk space. > > Is that reasonable - or at least possible? Does it mean I should do > something to compact the original copy? That's a pretty big difference but I suppose it's possible it's ok. Could be a consequence of rep-sharing. If "svnadmin verify" says both repositories are ok, they should be ok. You could check that they have the same number of revisions, and check out a few random revisions of each repository and then diff the results to convince yourself they're the same.
Reintegrate a branch issue
Hello, I created a development branch and I'm trying to reintegrate that branch back into the trunk. My question is two-fold: 1) After reintegration, I can delete my branch, correct? 2) When I attempt to reintegrate, I am getting the following error: Error: Retrieval of mergeinfo unsupported by '...my repo path...'. The research that I've done suggested I need to upgrade my server version of Subversion, but I would like to avoid doing this because of the corporate red tape. Any other suggestions? Thanks!
help me!
Hi Subversion Team: venture to disturb you, would like to ask, why do not directly generate Subversion Binary Packages, as Tigris.org the DJ Heap, Branko Cibej and Troy Simpson them Which will lead, direct compilation with Apache modules can be attached to it? Because we own the development process may already contain a local Apache, and third-party development mode which can not DJ they just single hook into Apache, so you can go to a lot of trouble. Wish you were able to find time to reply to my right? Thanks very much. andy 2010.05.22
