Re: cvs2svn failing on "non-CVS" files
On Thu, Sep 13, 2012 at 5:32 AM, Andreas Tscharner wrote: >> /data/cvs/tusk/ocw/tmpl/Attic/header,v >> Processed 5345 files >> Pass 1 complete. >> == >> = >> Error summary: >> ERROR: '/var/www/cvs/module/badfile,v' is not a valid ,v file >> >> Has anyone had fun and experience with CVS files that work in CVS, but >> break cvs2svn? Are there any particular pointers? Any guidelines on >> repairing such mangled files? > > We have had similar errors when we changed. The only solution I had was to > remove these files from the CVS repo and finally re-add them in the svn repo. > Of course this works only if there are only a few files (it was 6 in our case) Found it Someone put comments in among the numerical names of revisions in the beginning of the file, so it looked like this: 1.100 1.99 1.98 * Things had to be restructured at 1.97 Problems with layout 1.97 1.96 Once I stripped out the commentary in the weird location, everything seems to work. I have developer with the code verifying their CVS branches. I'm unsure whether someone manually edited the files 6 years back, or there's some way to store such comments there gracefully, but clipping that commentary seems to resolve the cvs2svn conversion. > The actual cause in our case was: CVSNT (!) has saved these files (they were > all binary) with a '0' somewhere in the file what the converter didn't like... Ouch.
REGRESSION in 1.7.6: * move mod_dontdothat to install-tools (r1307177)
Hello, Users. Now tools could not be built and installed without installed apache, even if mod_dav_svn is disabled at configure stage. -- // Black Lion AKA Lev Serebryakov
Re: REGRESSION in 1.7.6: * move mod_dontdothat to install-tools (r1307177)
Did you search the lists archives? It's been reported and a fix is nominated for backport to 1.7.7 in the STATUS file. Lev Serebryakov wrote on Fri, Sep 14, 2012 at 15:33:15 +0400: > Hello, Users. > > Now tools could not be built and installed without installed apache, > even if mod_dav_svn is disabled at configure stage. > > -- > // Black Lion AKA Lev Serebryakov >
RE: Problem with merging
Thanks Ryan, sent them a suggestion. Don't know if they'll like it, but we'll find out. John -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Thursday, September 13, 2012 4:46 PM To: John Maher Cc: Stefan Sperling; users@subversion.apache.org Subject: Re: Problem with merging On Sep 13, 2012, at 08:23, John Maher wrote: > How hard is it to change the book? I know what it means now, but the > next person may get confused. I would bet that someone will eventually > get confused. If it said "repository tree" like the FAQ I would bet it > helps. Book feedback should be sent to the book's authors. Go to: http://svnbook.org/ and scroll down to the "Feedback/Contributing" heading.
Re: REGRESSION in 1.7.6: * move mod_dontdothat to install-tools (r1307177)
On Fri, Sep 14, 2012 at 03:33:15PM +0400, Lev Serebryakov wrote: > Hello, Users. > > Now tools could not be built and installed without installed apache, > even if mod_dav_svn is disabled at configure stage. See http://subversion.apache.org/docs/release-notes/1.7.html#mod_dontdothat-issue
Why main Makefile don't use INSTALL_PROGRAM, only INSTALL? It causes installed binaries to be not stripped.
Hello, Users. Now Makefile.in contains: INSTALL = @INSTALL@ ... INSTALL_BIN = $(LIBTOOL) --mode=install $(INSTALL) And after configure it is expanded to: INSTALL = /usr/bin/install -c -o root -g wheel ... INSTALL_BIN = $(LIBTOOL) --mode=install $(INSTALL) It means, that all binaries are installed un-stripped. It is huge amount of unneeded (unless --enable-debug is provided) information, especially for static build. In case of dynamic build, all shared libraries are unstripped too. `configure' script defines INSTLAL_PROGRAM with additional `-m 555 -s' options, but it is not used. Why is it done in such way? Could it be changed? Yes, I've search mailing list this time without any relevant results. -- // Black Lion AKA Lev Serebryakov
Re: Problem with merging
On Thu, Sep 13, 2012 at 09:23:54AM -0400, John Maher wrote: > How hard is it to change the book? Check out the book sources, make changes, and either send a patch (i.e. the output of "svn diff" showing your changes) to the svnbook development list, or file an issue in the book's issue tracker and attach the patch to the issue. You can create a patch file like this from the top of your book sources working copy: svn diff > my-changes.patch See "Feedback / Contributing" on http://svnbook.red-bean.com/ for more information. If you want to compile your edited book sources before submitting your changes, which is a good idea in case you're not just making simple tweaks to the text but also add or change XML tags, see http://svnbook.googlecode.com/svn/trunk/en/README
RE: Problem with merging
Thank you Stefan. Very helpful. John -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, September 14, 2012 10:24 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On Thu, Sep 13, 2012 at 09:23:54AM -0400, John Maher wrote: > How hard is it to change the book? Check out the book sources, make changes, and either send a patch (i.e. the output of "svn diff" showing your changes) to the svnbook development list, or file an issue in the book's issue tracker and attach the patch to the issue. You can create a patch file like this from the top of your book sources working copy: svn diff > my-changes.patch See "Feedback / Contributing" on http://svnbook.red-bean.com/ for more information. If you want to compile your edited book sources before submitting your changes, which is a good idea in case you're not just making simple tweaks to the text but also add or change XML tags, see http://svnbook.googlecode.com/svn/trunk/en/README
Re: Problem with merging
John Maher wrote on Thu, Sep 13, 2012 at 10:26:39 -0400: > Yes that is what I did. Now that I know that causes problems with the > subversion mailing list I won't do it again. > For completeness... http://subversion.apache.org/docs/community-guide/mailing-lists#fresh-post
Re: problem with dialog box uisng Tortoisesvn
Carmit Shiran wrote on Wed, Sep 12, 2012 at 13:12:52 +0200: > If you look at my example I sent in the previous email, you can see I > filled in the argument= $target_path : > my $target_path = "file:///C:/svn_repos3/trunk/Widget3" > But I'm looking for a way to fill it automatically with the "current > path/tag". > Is it possible? Have a look at svn:keywords. Something like my $foo = <<'EOF'; $URL$ EOF is probably the best readable. And if no one said that already, remember that if you share a repository with other people it's recommended _not_ to use file://.
Re: AuthzSVNAccessFile and [alias]
To clarify, you want the left-hand side of an alias line to be the full DN, right? How is this going to work? Does our ini parser allow the LHS to contain embedded '=' sign? https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/config_file.c http://docs.python.org/library/configparser Esmond Pitt wrote on Wed, Sep 12, 2012 at 16:08:00 +1000: > The value of an alias in the AuthzSVNAccess file seems constrained to be > whatever login name the user used. > > However I am using LDAP authentication, and it is preferable for me for it > to be the full DN of the user rather than whatever he supplied as the login > name. > > I have 'AuthLDAPRemoteUserIsDN on', which promotes this behaviour for the > REMOTE_USER variable within Apache. > > Is there a way of propagating that behaviour to the AuthzSVNAccess file? > > Thanks in advance > > EJP
Re: Limit general read-operations to svn-repo
Stefan Bauer wrote on Thu, Sep 13, 2012 at 10:20:06 +0200: > Dear Users, > > We're having around 40 repositories. > > I'm trying to limit write access to a specific group per repository > and all read access to a group. How can i achieve this? > > I was able to limit the write operations with: > > > > Require ldap-group CN=svn-repo-install-read > > > > > But how can i set a general Limit for all repos below /svn/ for > read? ... is not working: > > First of all you probably want to anchor that regex. (use '^') > Require ldap-group CN=SVN_user > > > I would like to have that users prompted for credentials when they > try to read from repos below /svn and the credentials are checked if > the user is part of SVN_user. > Can't http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html do what you need ?? > Thank you in advance > > Stefan
Re: svndumpfilter and empty revisions
Can you post the actual parts of the dumpfile for those empty revisions? (between successive "Revision-number: " lines) David Newman wrote on Wed, Sep 12, 2012 at 12:02:29 -0400: > Hi there, > I have received a subversion dump file that contains about 12000 empty > revisions. There's only one subdirectory in the dump filter so I figured I > could run it through svndumpfilter include subdir --drop-empty-revs > --renumber-revs < src.dmp > filtered.dmp and because the empty revs don't > contain any nodes they'd get filtered. However, the empty revisions pass > through and end up in the filtered dump file. The empty revisions contain > only two things, a svn:log property and a svn:date property. > > Is this a bug? > > -Dave
Re: Malformed Network Data Error accessing svnserve on OS X Server 10.8
If you telnet or netcat to the host on port 3690, what do you get?
The expected answer is, "The same output I get when I run 'svnserve -i'
on the server".
Larry Goldman wrote on Tue, Sep 11, 2012 at 16:46:29 -0700:
> I'm attempting to get svnserve running on OS X Server 10.8.
>
> I have successfully installed the client and server (using Fink).
>
> When starting svnserve from the command line ("svnserve -d -r /Groups/svn"),
> the client lists the repository contents successfully.
>
> When I start svnserve via launchd as specified in the Red Book, the client
> reports: Malformed network data.
>
> I believe I have the correct launchd .plist.
>
> I have tried this with SVN version 1.7.5 and 1.6.18. Both can connect OK from
> command line, but report Malformed Network Data for launchd invocation.
>
> Any ideas?
>
> Thanks,
>
> Larry Goldman
