Re: Downgrade repository's version (1.4->1.3) without losing local modifications

Thank you all for answers, of course I meant working copy and mistakenly used term "repository". Erik, I thought about solution you proposed but how can I deal with added/deleted files? I have plenty of them... -- Regards, Sergei Dyshel On Wed, May 26, 2010 at 23:18, Erik Andersson wrote: > Wh

Re: truMerge 1.1.0 released

Checked out the website, and there doesn't seem to be much up on truMerge; it took me a while to find out it needs the command-line 1.5 series client to function. More info on the website would be useful - especially requirements, supported platforms, a working Wiki, etc. (No, I didn't log into

Re: Strange status if .svn folder removed

On Thu, May 27, 2010 at 7:06 AM, Steve Armstrong wrote: > Hello all, > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 > command-line binaries. > > I have a working copy checked out (C:\wc). Inside it, there's an empty > folder that's source-controlled (C:\wc\logs). If I dele

Re: Strange status if .svn folder removed

Wow, that was a fast reply. Ok, I'll just work around it for now then. Thanks for getting back to me. On Wed, May 26, 2010 at 5:16 PM, Hyrum K. Wright < hyrum_wri...@mail.utexas.edu> wrote: > > > On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong < > steve.armstr...@gmail.com> wrote: > >> Hello al

Re: Strange status if .svn folder removed

On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong wrote: > Hello all, > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 > command-line binaries. > > I have a working copy checked out (C:\wc). Inside it, there's an empty > folder that's source-controlled (C:\wc\logs). If I dele

Strange status if .svn folder removed

Hello all, I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 command-line binaries. I have a working copy checked out (C:\wc). Inside it, there's an empty folder that's source-controlled (C:\wc\logs). If I delete the .svn folder from within logs, then doing an "svn st" in the ba

RE: SVN merge issue in Solaris

Hi Johan, We are running on solaris zone and able to run truss on the process, we see majority of time svn spends is in reading the .svn/entries file again and again. Why is that. Thanks Sal getcwd("/opt/projects/common_services/rjm/autsys-workspace/workspace/merge_test/MERGE_TEST", 1024) =

Re: SVN merge issue in Solaris

On Wed, May 26, 2010 at 9:20 PM, Liu, Xiaodu "Louie" wrote: > We have the svn merge performance issue on Solaris.  For a given repo, if > we do svn merge on windows box, it takes about 35 seconds, but same merge > will take about 6 minutes. > > Both svn version 1.6.6 and 1.6.11 clients are tested

Re: Downgrade repository's version (1.4->1.3) without losing local modifications

What about: On B: svn diff working_copy > localmods.patch On A: svn co new_working_copy patch < localmods.patch Not sure about the syntax, but the strategy should work? Cheers / Erik On Wed, May 26, 2010 at 10:13 PM, Jeremy Whitlock wrote: > > There is a script floating around somewhere that w

Re: Downgrade repository's version (1.4->1.3) without losing local modifications

> There is a script floating around somewhere that will do it. http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py But as you'll see, it only works with 1.4+. Take care, Jeremy Whitlock Twitter: jcscoobyrs Website: http://www.thoughtspark.org

RE: Downgrade repository's version (1.4->1.3) without losing local modifications

> On May 26, 2010, at 14:54, Sergei Dyshel wrote: > > > I have a single checked out SVN repository, shared between 2 machines > (lets call them A and B). Until now I was using it only on A which has SVN > 1.3 installed. Today I updated it on B which has version 1.4 installed. It > turned out that

Re: Downgrade repository's version (1.4->1.3) without losing local modifications

On May 26, 2010, at 14:54, Sergei Dyshel wrote: > I have a single checked out SVN repository, shared between 2 machines (lets > call them A and B). Until now I was using it only on A which has SVN 1.3 > installed. Today I updated it on B which has version 1.4 installed. It turned > out that re

Re: Downgrade repository's version (1.4->1.3) without losing local modifications

On Wed, May 26, 2010 at 15:54, Sergei Dyshel wrote: > Hello, > I have a single checked out SVN repository, shared between 2 machines (lets > call them A and B). Until now I was using it only on A which has SVN 1.3 > installed. Today I updated it on B which has version 1.4 installed. It > turned ou

Downgrade repository's version (1.4->1.3) without losing local modifications

Hello, I have a single checked out SVN repository, shared between 2 machines (lets call them A and B). Until now I was using it only on A which has SVN 1.3 installed. Today I updated it on B which has version 1.4 installed. It turned out that repository's internal structure's version was bumped fro

SVN merge issue in Solaris

We have the svn merge performance issue on Solaris. For a given repo, if we do svn merge on windows box, it takes about 35 seconds, but same merge will take about 6 minutes. Both svn version 1.6.6 and 1.6.11 clients are tested with the same issues. Please help! Thanks Louie *

Re: compact repository (many files)

On Wed, May 26, 2010 at 19:07, Paul Ebermann wrote: > Mark Phippard wrote: >> On Wed, May 26, 2010 at 11:53 AM, Paul Ebermann wrote: > [...] >>> Is there any way to reduce the file number of the repository without >>> throwing away >>> information? As in, throw the changes in revisions 0 ... 999

Re: compact repository (many files)

On Wed, May 26, 2010 at 13:07, Paul Ebermann wrote: > Mark Phippard wrote: >> On Wed, May 26, 2010 at 11:53 AM, Paul Ebermann wrote: > [...] >>> Is there any way to reduce the file number of the repository without >>> throwing away >>> information? As in, throw the changes in revisions 0 ... 999

Re: compact repository (many files)

On Wed, May 26, 2010 at 12:07 PM, Paul Ebermann wrote: > ... > I think packing the revprops would (from a space viewpoint) be even more > useful than > packing the revisions, since most of these are quite small (similar) text > files. > > Statistics: only 91 of those have a size of more than 150 b

Re: compact repository (many files)

Mark Phippard wrote: > On Wed, May 26, 2010 at 11:53 AM, Paul Ebermann wrote: [...] >> Is there any way to reduce the file number of the repository without >> throwing away >> information? As in, throw the changes in revisions 0 ... 999 together in one >> file (and >> this way even safe some spa

Re: svn support for symbolic link?

On Tue, May 25, 2010 at 6:44 PM, Keith Moore > > I tried this on Windows 7 Enterprise with > TortoiseSVN 1.6.8, Subversion 1.6.11 and got the error message "svn: > Symbolic links are not supported on this platform".  Now, I know these > error messages can be a bit cryptic so I googled this one

Re: compact repository (many files)

On Wed, May 26, 2010 at 05:53:17PM +0200, Paul Ebermann wrote: > The problem now is that I have a quota limitation of 3 files here > (additionally to a > size limit), and my svn repository fills now about 1/6 of this, steadily > growing, forcing > me to delete other files ... > > Is there an

Re: compact repository (many files)

On Wed, May 26, 2010 at 11:53 AM, Paul Ebermann wrote: > I have here a personal Subversion repository hosted on my university account > (for easy > access from everywhere via SSH). (Its format is a 1.5 FSFS, from the > information in the > meta-files.) > > I'm now to revision 2529, which means

RE: compact repository (many files)

I wish I had an answer for you. We have a similar situation. I manage a dozen production SVN Repos and some are getting quite large. One repo has over 35,000 revisions. Some of the original revisions from years ago I'd like to extract and archive and just maintain the archive with history fo

compact repository (many files)

Hello, I have here a personal Subversion repository hosted on my university account (for easy access from everywhere via SSH). (Its format is a 1.5 FSFS, from the information in the meta-files.) I'm now to revision 2529, which means the whole repository has 5098 files (most of them in db/revs

apache2, subversion, active directory, LDAPs authentication failures

I have encountered a problem for which I've been unable to find a solution. Using RHEL 5.4 my configuration (slightly obscured for security) below appears to be working in that requesting the defined location triggers an auth prompt. However when using a correct username & password authentication

Re: truMerge 1.1.0 released

On Wed, May 26, 2010 at 12:17:38AM +0200, Schellingerhout, Nico wrote: > Dear Subversion users, > > I am happy to announce the release of truMerge 1.1.0. > > truMerge is a merge helper tool that combines true > rename > functionality