Re: Using * in AuthzSVNAccessFile file
On Thu, May 20, 2010 at 10:48 PM, vishwajeet singh dextrou...@gmail.com wrote: On Fri, May 21, 2010 at 2:16 AM, Prakash Velayutham prakash.velayut...@cchmc.org 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: Maxsize of Properties
Von: Ryan Schmidt subversion-20...@ryandesign.com 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.
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 subversion-20...@ryandesign.com 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, ullrich.j...@elektrobit.com 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
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 roger.tal...@uc4.com 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 roger.tal...@uc4.com 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
