Re: File not accepted as valid addition to svn

[Dave Huang]

On 2/12/2018 11:41, Bo Berglund wrote:

On Mon, 12 Feb 2018 15:54:00 +, Philip Martin
<phi...@codematters.co.uk> wrote:


'&' has special meaning to the shell and needs to be quoted or escaped.

I always thought that this was the case only for Linux, since & is a
perfectly valid part of a file name on Windows...
But I will refrain from such characters in paths in the future.



& is valid for a filename on Linux too, but it also needs to be escaped 
there... if you run "help cmd" in Windows, it says at the end:


The special characters that require quotes are:
 
 &()[]{}^=;!'+,`~

The & in Windows is a command separator, basically like ";" in 
Unix-style shells. So


svn add Fasadändring

Is interpreted as "svn add Fasadändring" followed by "Attefalltillbyggnad.pdf". The first results 
in "svn: warning: W155010: 'D:\Bosse\Fasadändring' not found", and the second results in 
"'Attefalltillbyggnad.pdf' is not recognized as an internal or external command, operable program or batch 
file."

Also, "^" is the escape character for cmd.exe (like "\" in Unix shells), so as 
an alternative to quoting the filename, you can do:

svn add Fasadändring^

--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
Telegram: @dahanc|  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 41 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: inodes usage of svn server

[Dave Huang]

On 1/3/2018 13:19, Nico Kadel-Garcia wrote:

NTFS also has limits on the maximum number of files for a filesystem.


FWIW, that limit is 2^32 - 1 files, or approximately 4 billion (see 
Table 3.12 of https://technet.microsoft.com/en-us/library/cc938432.aspx)



There are also notable performance limits on having too many files in
a directory.


I don't know enough about NTFS internals to say whether that's the case 
with NTFS or not, but in the context of this discussion, the default SVN 
shard size is 1000 revisions, which I don't think could be considered 
"too many files in a directory".


While I don't have any actual numbers, my gut feeling is that packing 
the repo isn't really needed on NTFS in terms of day to day performance 
of clients using the repo, or in terms of filesystem limitations. That 
said, I do it anyway because backing up the repo does go faster when 
dealing with a couple dozen large files vs. tens of thousands of small 
files.


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
Telegram: @dahanc|  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ 
PL++

Re: Hiding Subversion version number

[Dave Huang]

On 12/16/2017 5:38, Branko Čibej wrote:

On 15.12.2017 16:15, Dhanushka Parakrama wrote:

Hi All

Is there any configuration where i can hide  the subversion version
details .Please see copied image Inline images 1


You could start by telling us *where* you see that image. In a browser,
I presume? Generated by which server? It's certainly not generated by
Subversion so I wonder if you're on the right list?

-- Brane


Of course it's generated by Subversion. mod_dav_svn, to be more precise. 
Just Google for "Powered by Apache Subversion" to find tons of examples, 
e.g., https://svn.openstreetmap.org/


See also: 
http://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l3547


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
Telegram: @dahanc|  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ 
PL++

Re: Hiding Subversion version number

[Dave Huang]

On Dec 15, 2017, at 9:15, Dhanushka Parakrama <parakrama1...@gmail.com> wrote:
> 
> Hi All
> 
> Is there any configuration where i can hide  the subversion version details 
> .Please see copied image 

I think that's controlled by the Apache ServerSignature configuration option 
(https://httpd.apache.org/docs/2.4/mod/core.html#serversignature 
<https://httpd.apache.org/docs/2.4/mod/core.html#serversignature>)

-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
Telegram: @DahanC|  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 42 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: svn+ssh very slow, but ssh is just fine - difference in socket calls?

[Dave Huang]

On 10/4/2016 12:26, Karen Pease wrote:


As it says on the tin, our connections via svn+ssh are painfully slow, 
yet we can ssh into the server without any delays whatsoever.  A find 
on the subversion repository likewise whips through without delay, and 
there's no memory or CPU load on the server when people are 
connecting.  So all signs point to some sort of connection or 
authentication delay.



I ran ssh through strace and compared that to a svn connection through 
strace.  Here's where things go awry.  First, SSH which works:



socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3

connect(3, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("{{Our IP}}")}, 16) = 0




Now, note the difference on the socket call.  Ssh uses a socket call 
with SOCK_STREAM / TCP, while svn+ssh uses SOCK_DGRAM|SOCK_NONBLOCK / 
IP.  Why would it do that?  That doesn't make any sense to me.  How 
can I change this?




Note the port number on that SOCK_DGRAM socket: 53. That's DNS. Is your 
DNS server working properly? It sounds like it's timing out waiting for 
a response from the DNS server.

Re: Subversion 1.8.14 won't install on OSX

[Dave Huang]

On Nov 9, 2015, at 4:22, Alexander Henket  wrote:
> 
> Right, that's it. I downloaded the zip variant. Don't know why it should 
> matter, but anyway. It's working now .. sort of:

While zip works just about everywhere these days, it has its origins in the 
MSDOS world, and Windows can extract zip files without any 3rd party utilities, 
so I think the zip variant is intended to be more convenient for Windows users.

> Any other hints? Thanks in advance.

What about the WANdisco package? It's for Yosemite, but it seems like it should 
work on El Capitan too.

FWIW, MacPorts subversion 1.9.2 installed with no problems on my El Capitan 
system. What did 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_db46/db46/main.log
 have to say about the problem?

Re: Subversion 1.8.14 won't install on OSX

[Dave Huang]

On Nov 8, 2015, at 23:31, Alexander Henket  wrote:
> 
> Hi,
> 
> Tried to build Subversion 1.8.14, but: there is no "configure" and all *.sh 
> files are Windows CRLF formatted so they do not work before conversion. I do 
> not have autogen.

Maybe you downloaded from the wrong place? 
http://www.us.apache.org/dist/subversion/subversion-1.8.14.tar.gz 
 has 
configure:

$ tar tzf subversion-1.8.14.tar.gz | grep configure
subversion-1.8.14/configure
subversion-1.8.14/configure.ac

and "grep -rl '\r' subversion-1.8.14" doesn't show any *.sh files with CRs in 
them (there are various files with CRs in them, in particular test files under 
subversion/tests, but they're binaries)

> Doesn't anybody distribute the latest binaries for OSX?

http://subversion.apache.org/packages.html#osx 

Re: svnrdump produce a strange dump file

[Dave Huang]

On Oct 1, 2015, at 8:29, Nico Kadel-Garcia  wrote:
> 
> On Thu, Oct 1, 2015 at 4:19 AM, Yves Martin  wrote:
>>  Hello,
>> 
>> I have a Subversion 1.6.17 server running on Debian Linux and access through
>> HTTPS.
>> 
>> I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump
>> of the repository:
> 
> *Why*? If you have a subversion 1.6.17 server, why wouldn't you use
> the the local svnadmin dump command for maximum binary compatibility?
> I'm not saying it shouldn't work, just wondering why you're even
> bothering.

I interpreted "access through HTTPS" as meaning the *only* access is through 
HTTPS. svnadmin requires a local shell on the server.

Re: question about subversion 1.9 unicode normalization status

[Dave Huang]

On Aug 12, 2015, at 4:00, Branko Čibej br...@wandisco.com wrote:
 
 Yay for misunderstandings. :)
 
 The problem with HFS is that it normalizes paths: regardless of how your
 file names are (de)normalised when you create them, they're stored in
 HFS in NFD form.

I don't think I misunderstood anything; I said in my message that filenames are 
stored in NFD, and that I don't think that's broken: But while HFS(+) is old 
and is due for an overhaul, its use of Unicode NFD isn't broken.

That's great that you're working on the issue though. While I only work in 
English these days and am not affected by this problem, I used to work at a 
place were a lot of l10n stuff was going on, and saw all sorts of languages and 
accented letters :)
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: question about subversion 1.9 unicode normalization status

[Dave Huang]

On Aug 11, 2015, at 15:35, Branko Čibej br...@wandisco.com wrote:
 
 On 10.08.2015 18:46, Attila Soki wrote:
 hi,
 
 i saw the entry reimplement UTF-8 fuzzy conversion using utf8proc 
 (r1511676)
 in the changelog and hoped this would be the fix for
 http://subversion.tigris.org/issues/show_bug.cgi?id=2464
 
 but after a quick test it seems to be still broken.
 
 In my not even a bit humble opinion, what's broken is Apple's HFS, not
 Subversion.

Exactly what is broken in Apple's HFS? MacOS uses one of the Unicode 
Normalization Forms. Perhaps it's not the same one that Windows uses, but 
there's nothing wrong with that. While it's unfortunate that SVN didn't handle 
this correctly from the start, it doesn't make it Apple's fault. Unicode 2.0 
talked about normalization/canonicalization in 1996, and TR 15 has been around 
since about the same time--both predating SVN's development by years. Of 
course, most people weren't thinking about Unicode back then, and a filename 
was considered to be some opaque string of bytes, so I don't particularly blame 
SVN either. If anything, Unicode should've just declared one canonical form 
instead of giving options. But while HFS(+) is old and is due for an overhaul, 
its use of Unicode NFD isn't broken.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Svn rename doesn't copy custom properties

[Dave Huang]

On 30.04.2015 01:23, Dan Ellis wrote:

OK, so it gets stranger...

I admit I changed the property names a bit to simplify them.  When I
ran the simplified names, it does work.


Do you perhaps have some commit hook scripts on the server that look for 
those properties and do special things with them?

Re: Getting Subversion Exception while SVN Upgrade working copy

[Dave Huang]

On 2015-03-26 6:08, Stefan Hett wrote:

Hi,

maybe better to start this of on the TortoiseSVN mailing list (since 
that's the client you seem to be using).


TortoiseSVN uses the Subversion library, which is where the exception is 
coming from. Also, the message explicitly says to report it on the 
Subversion mailing list, not the TortoiseSVN list.


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: mod_dav_svn.so does no more support lock functions

[Dave Huang]

On 2015-01-06 10:57, Thierry LEPINE wrote:

Not the official for sure but the most common download site

http://sourceforge.net/projects/wampserver/

http://sourceforge.net/projects/win32svn/


http://www.wampserver.com/en/ says Once WampServer is installed, you 
can manually add aditionals Apache, Php or MySql (only VC9, VC10 and 
VC11 compiled) versions. I think that means addon modules must be 
compiled with VC9, 10, or 11. http://sourceforge.net/projects/win32svn/ 
says that the SVN modules are build with VC++ 6.0.


I think you need to get binaries of Apache and SVN that have been 
compiled with compatible compilers. I'm using the 
http://www.apachehaus.com/ binaries, and they're working well.


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Windows 8 Tortoise SVN --- missing green check marks

[Dave Huang]

On Oct 13, 2014, at 8:09, John Maher jo...@rotair.com wrote:
 Tortoise doesn’t display the check marks on windows 7 either.  Tortoise is a 
 great concept, providing  a modern interface for a powerful tool, however, it 
 is not being kept up to date as it should.

FYI, it displays the status overlays on Windows 7, 8, and 8.1--I use TSVN on 
Win8.1 daily and have the check marks, etc... The TSVN documentation even shows 
them on Windows 7; I'm pretty sure figure 4.12 at 
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-wcstatus.html is 
from Windows 7, and Figure 4.13 is definitely Windows 7.

As others have mentioned, if you're having problems with the overlays not 
showing, ask the TortoiseSVN mailing list. And check this FAQ item too: 
http://tortoisesvn.net/faq.html#ovlnotshowing

-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Windows 8 Tortoise SVN --- missing green check marks

[Dave Huang]

On Oct 13, 2014, at 10:26, John Maher jo...@rotair.com wrote:

 Hi Dave
 
 What version of tsvn are you using.  Perhaps I have an older version?

The current one, TortoiseSVN 1.8.8 (64-bit).

Re: Blocking root from SVN repository

[Dave Huang]

On Aug 27, 2014, at 10:08, Zé jose.pas...@gmx.com wrote:

 On 08/27/2014 03:53 PM, Les Mikesell wrote:
 It's not that you can't use it, just that it can't protect you from
 the things that can happen through direct file system access.  Like
 accidentally deleting the whole repo or changing ownership or
 permissions.
 
 But regarding my question, if file:// is not intended to be used, as you and 
 Stefan Sperling argued

Pretty sure Les just said, It's not that you can't use it. Which means you 
*can* use it. So the question you keep asking is based on a false premise.

Re: Unable to browse repo

[Dave Huang]

On 2014-02-12 11:46 AM, C M wrote:
For what it's worth, line 93 refers in the config file is listed 
below. As far as I know, this file hasn't been modfied recently by 
anyone. At least that's what my team members tell me.



 92  ### put last-committed timestamps on every file touched.
 93   use-commit-times = yes
 94  ### Set no-unlock to prevent 'svn commit' from automatically


It looks like there's a space at the beginning of line 93... try 
removing it.

Re: ignore property not ignoring...

[Dave Huang]

On Jan 10, 2014, at 16:17, Edward Ned Harvey (svn4) s...@nedharvey.com wrote:

 Can someone please explain this to me?  I would expect bin and obj not to 
 show up in the svn status command, because of the svn:global-ignores 
 property.

 The mac client is 1.7, and the windows client is 1.8 if that makes any 
 difference.  These are separate working copies.  I would not expect the two 
 clients to be compatible with each other on a shared WC.

It does; svn:global-ignores is new to SVN 1.8. 
http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config

If you upgrade the Mac client to 1.8.x, it should honor svn:global-ignores.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: SQLite appears to be compiled without large file support

[Dave Huang]

On 2013-12-05 1:16 AM, David Kelly wrote:
Repeat adding -s to ls. I think that will list the position of EOF. I 
think you have a sparse file which physically occupies 119k but has 
massive holes which have yet to be assigned disk blocks.


It's the other way around-- ls -l shows the logical length of the file, 
and ls -s shows the actual number of blocks used.


E.g.

$ dd if=/dev/zero of=sparse count=1 seek=1
1+0 records in
1+0 records out
512 bytes transferred in 0.001 secs (512000 bytes/sec)
$ ls -ls sparse
64 -rw-r-  1 khym  wheel  5120512 Dec  5 09:09 sparse

Re: IPv6 URL support in SVN? v1.8.4 works with IPv4, not with IPv6

[Dave Huang]

On Nov 2, 2013, at 12:48, d...@sent.com wrote:

 With my resolvers set to IPv6
 
   cat /etc/resolv.conf
   nameserver 2600:3c01::2 
   nameserver 2600:3c01::3
   options rotate

 in short, 'everything' IPv6 works here ... except for subversion,

FWIW, changing your nameservers is unrelated to whether a site will be accessed 
over IPv4 or IPv6--it only affects whether the *nameserver* will be accessed 
over IPv4 or IPv6. Lookups will still return  records even if all of your 
nameservers are IPv4.

In any case, I can access a SVN repos over HTTP to an IPv6 address using 
TortoiseSVN 1.7.x and 1.8.x, but I only have IPv4 nameservers. From the error 
message you're getting, it looks like svn is having trouble resolving 
www.nlnetlabs.nl when your nameservers are IPv6. However, when your nameservers 
are IPv4, I suspect svn will still connect to www.nlnetlabs.nl over IPv6. You 
can use tcpdump to confirm, or if you have access to them, look at the logs on 
www.nlnetlabs.nl.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Windows file:/// URL format for svnsync

[Dave Huang]

On Oct 31, 2013, at 15:17, David Goldsmith eulergaussriem...@gmail.com wrote:

 OK, now we're going in circles: what you cut and paste is what I've been 
 trying, over and over again, to no avail (as I said in my OP, it didn't like 
 the way I'm specifying my source folder.)  I'm sure there's some subtlety 
 that--as a user, not an admin--I'm missing, that those overly-simplified 
 instructions aren't including, but I can't seem to communicate what it is.  
 I'll try posting a transcript of my efforts.

Well, earlier, you said:

 As I think about my sitch, I realize that the folder I thought was the root 
 of the repository probably isn't, because it's the root of the directory tree 
 in which reside all the files that I edit day-to-day, and that's supposed to 
 be a working copy, not the repository itself, correct?

So I take that to mean C:\MWDM is the working copy, not the repository. You 
need the repository URL. In response to your message, Bert Huijben gave 
instructions on how to find the repository URL:

 ‘svn info WORKINGCOPY’ will tell you the url in the repository and the 
 repository root.

However, it seems like you're still using file:///C:/MWDM as the repo URL, 
rather than the what svn info gave.

Re: Switching

[Dave Huang]

On Aug 22, 2013, at 13:39, John Maher jo...@rotair.com wrote:

 You digress.  Not a single one of the compiled libraries lives within the 
 versioned directories.  Please read the question before replying incorrectly. 
  It has nothing to do with code.  It has nothing to do with the build.  
 Please ask for clarification if you do not understand.  You gave a good 
 suggestion with the force option.  Then you wandered off to completely 
 irrelevant ramblings.  Should quit while you're ahead.

It's getting obvious that you're not actually interested in the solutions the 
list has to give :(

Re: Tortoise SVN is not listed on binary packages page

[Dave Huang]

On 7/11/2013 12:50 PM, Mark Mikofski wrote:
I was looking for a comprehensive list of SVN clients to link to, and 
I was surprised to see that TortoiseSVN http://tortoisesvn.net/ is not 
listed on the packages page 
http://subversion.apache.org/packages.html#windows.


I suspect TortoiseSVN isn't included because it falls under this: Note 
also that this list does not include distributions of larger collections 
of software of which Subversion is but one piece.


The page is a list of Apache Subversion Binary Packages, not all SVN 
clients--while TortoiseSVN's installer does optionally let you install 
the Apache Subversion commandline client, its main purpose is to install 
TortoiseSVN.

Re: Advice for changing filename case in SVN on case insensitive system

[Dave Huang]

On 6/20/2013 5:34 PM, Geoff Hoffman wrote:
We have a bunch of Kohana 3.2 projects in revision control, all with 
lower case filenames.


We're upgrading to Kohana 3.3; one of the main changes to Kohana 3.3 
is implementing PSR-0 filename conventions, which require the class 
Model_Myclass to be found in Model/Myclass.php ... in our current repo 
it's in model/myclass.php (all lower case).


I thought I could just svn rename, however I'm confused by the output 
I'm seeing:


svn rename myclass.php Myclass.php
svn: E155007: Path '/Full/Path/To/Myclass.php' is not a directory


Perhaps http://subversion.apache.org/faq.html#case-change might be helpful.

(Interesting/surprising that SVN 1.7 only fixed svn rename on Windows, 
but not on other OSes with case-insensitive filesystems like MacOS X)

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Dave Huang]

On May 19, 2013, at 3:20, Zé jose.pas...@gmx.com wrote:

 You are confused.  This discussion is about how subversion lacks any support 
 for branching, which is quite obvious to anyone who understands and 
 acknowledges that all subversion does is track revision changes to a file 
 system.

I use branches in SVN all the time… you might take a look at the SVN Book for 
documentation if you're confused about how to do it: 
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html

HTH, HAND.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: data encryption

[Dave Huang]

On 2/5/2013 4:09 PM, Thorsten Schöning wrote:

Guten Tag Hector Magnanao,
am Dienstag, 5. Februar 2013 um 19:29 schrieben Sie:


Thanks, I guess my question wasn't so clear.  I was asking for
something or a suggestion on how to encrypt data from Subversion.

This doesn't sound more clearly to more than the question before. :-/


I think he means he wants to know how to encrypt data transmitted 
between the Subversion server and the client... in which case, check the 
documentation on how to set up access to the repository through SSH 
and/or HTTPS. 
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html#svn.serverconfig.choosing.svn-ssh

Re: Cannot add files which contain '@' in filename

[Dave Huang]

On Nov 25, 2012, at 3:13, Nick nos...@codesniffer.com wrote:

 Thanks.  Is it possible/valid to specify a peg revision when adding files?  
 If not, does it make sense for SVN to not attempt to interpret the '@' 
 character for this operation?

Hmm, that's a good point--it doesn't seem like peg revisions make sense when 
adding files. I'm just an average svn user though; I'll leave it to someone 
more knowledgable to answer whether svn add should treat @ literally, rather 
than as a peg revision spec.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Cannot add files which contain '@' in filename

[Dave Huang]

On Nov 25, 2012, at 2:11, Nick nos...@codesniffer.com wrote:

 It seems like files with the '@' character in the name cannot be added to a 
 repo.  I've verified this in two different repos using SVN version 1.6.17.

 Is this a bug?

No, it's sort of hidden, but it is mentioned in the documentation:

The perceptive reader is probably wondering at this point whether the peg 
revision syntax causes problems for working copy paths or URLs that actually 
have at signs in them. After all, how does svn know whether news@11 is the name 
of a directory in my tree or just a syntax for “revision 11 of news”? 
Thankfully, while svn will always assume the latter, there is a trivial 
workaround. You need only append an at sign to the end of the path, such as 
news@11@.

http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: SVN and PRN and CON files on Windows platform

[Dave Huang]

On Mon, Sep 24, 2012 at 12:57:38AM -0500, Ryan Schmidt wrote:

 It's not a bug in Subversion; it's a feature (or at least a
 reality that's unlikely to change) of the Windows operating system.
 On Windows, you may not create a file whose name is PRN, with any
 extension.

Actually, it *is* possible to work around the feature, although it's
not generally a good idea to do so, and I don't think svn should do
it: you can use the Windows API to create files with the old reserved
DOS device names by prefixing the pathname with \\?\.

E.g., Start - Run, notepad \\?\C:\temp\prn.txt , type some text, and
File - Save. (Substitute C:\temp with the path to a directory that
exists on your machine, of course)

The problem is that while svn could be changed to create a file with
reserved names, almost nothing else will be able to work with the
file. Try finding a program that can do anything with the prn.txt file
created above. You can't even delete it without jumping through hoops
(one way is to open a Command Prompt, and running del
\\?\C:\temp\prn.txt)
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: general questions

[Dave Huang]

On Tue, Sep 11, 2012 at 03:10:57PM -0400, John Maher wrote:
 Sorry I'm not reading anything on unix if I can help it.

With that statement, you've made it obvious that you don't actually
understand the capabilities of the CLI. Both CLI and GUI have their
uses, and it's definitely not the case that a GUI can do everything a
CLI can do (unless you kludge in CLI-like functionality into your
GUI... a textbox where you can type a CLI command isn't actually a
GUI; nobody considers xterm or Konsole or MacOS Terminal.app a GUI).
(And conversely, there are certainly things that are much more easily
done with a GUI than a CLI).
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: svn log: 1.7 and large limits

[Dave Huang]

On Jul 31, 2012, at 2:26 PM, Stefan Sperling wrote:

 The limit value is defined as an int (see opt_state defitinion in
 subversion/svn/cl.h). According to the C standard an int is always
 32bit in size, and signed.

FWIW, the C standard doesn't actually specify the absolute size of an int--it 
only specifies its size relative to the other integral types: sizeof(short) = 
sizeof(int) = sizeof(long)

That said, in practice, int is probably 32 bits on everything you'd want to svn 
on. It's 16 bits on some microcontrollers, for example. And I think it's 64 
bits on a supercomputer or two.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

svn cleanup fails because it can't find a temp file

[Dave Huang]

I tried to roll back some changes to a file by doing a reverse merge, 
but I had the file in question open and locked, so svn wasn't able to 
complete the merge. However, this has left my working copy broken and 
unrecoverable :( (I know I can do a clean checkout, but that's creating 
a new WC... the old one remains unrecoverable by normal means).


Pretty much any operation on the WC, such as svn log, fail with: svn: 
E155037: Previous operation has not finished; run 'cleanup' if it was 
interrupted


But svn cleanup doesn't work because: svn: E720002: Can't open file 
'C:\Users\Dave\AppData\Local\Temp\svn-C09EC58D': The system cannot find 
the file specified.


It's true that the file it's looking for isn't there, but why does it 
expect it to be there? It's in the Temp directory, and svn shouldn't 
expected things in there to stay around between different invocations of 
svn. That said, I didn't delete it myself--I assume svn must've deleted it.


The .svn/wc.db's WORK_QUEUE table contains:

3399|(file-install Data/DemoCA.zip 1 0 1 0 
C:/Users/Dave/AppData/Local/Temp/svn-C09EC58D)

3400|(sync-file-flags Data/DemoCA.zip)

Data/DemoCA.zip is the file I was trying to reverse merge. I deleted 
those two rows and was able to do a svn cleanup, but manually messing 
with the wc.db doesn't sound like a good idea.


So, why does svn cleanup fail if a temp file can't be found, and can 
something be done to remove that requirement? As I mentioned, I don't 
think svn should depend on temp files being persistent.


This is with svn 1.7.5 on Windows 7.

Re: Upgrade to v1.7 = death of working copies

[Dave Huang]

On 5/11/2012 1:45 AM, Julius Smith wrote:

 My experience was different - I could not check into the 1.6 server
 on Linux (with 1.6-format repo) from my 1.7-upgraded working copy
 (with 1.7 svn client) on the Mac.


Well, as mentioned by Lorenz, you didn't actually give any specifics of 
the problem, so there's not much anyone can do to help. But it's 
supposed to work, and in fact, does work--the subversion server at my 
place of work is still on 1.6.something, but all of the clients that 
access it are 1.7.4.



 That makes my point all the more forcefully.


If your point is that there should be compatibility between the 
versions, you seem to have missed my point that there *is* 
compatibility. 1.x servers are compatible with 1.x clients. Whatever 
problem you had has nothing to do with version incompatibility. If you 
were to show the commandline you used and the error that you got when 
you tried to commit, you might be able to get some more help.

Re: Upgrade to v1.7 = death of working copies

[Dave Huang]

On May 10, 2012, at 8:43 PM, Julius Smith wrote:

 On my MacBook, MacPorts upgraded me to subversion 1.7 at some point, and when 
 notified to upgrade my working copies, I did so.  My svn server is a Linux 
 machine running Fedora 16 (the most recent Fedora release of last November).  
 Unfortunately it does not offer subversion 1.7 and will only go up to 1.6.  
 (Version 1.7 is available in an alpha future version of Fedore, but I cannot 
 risk going to that on my server.) nCoincidentally, I was cut off from my 
 server for a week due to a spurious IP address change by comcast, so now I 
 cannot check in a week's worth of changes in several working copies.  I tried 
 downgrading to 1.6 in Mac Ports, but no matter what I do it insists on 
 installing 1.7, ignoring my specification of a 1.6 release that I know 
 exists.  So, three bug reports:
 
 1. MacPorts refusing to downgrade back to 1.6.
 
 2. Fedora not offering the latest stable version of subversion.
 
 3. Subversion allowing working copies to be upgraded without verifying that 
 they can be checked in afterwards.  In other words, the server should be 
 required to upgrade first.

I don't have any ideas about 1 and 2, but for #3, why would you need to upgrade 
the server first? All 1.x Subversion clients and servers are compatible with 
each other. You can use a 1.7 client with a 1.6 server (or a 1.0 server) if you 
want. This is mentioned in the FAQ: 
http://subversion.apache.org/faq.html#interop

 Also, what happened to compatibility across at least one major release 
 number?  I thought nearly all software packages did that.

Well, 1.6 and 1.7 are only a minor release number apart, so compatibility 
across a major release number doesn't seem to be applicable in this case.

Re: Subversion restore

[Dave Huang]

On 2/22/2012 11:11 AM, svenk1 wrote:

Hello.  I've read through some threads, but it seems that the scenarios
assume I have valid repo dumps.  I do not.

What I have is a new server, and the backups of the old server.  I installed
what I can only assume is a much newer version of subversion on the new
server.  I copied my repo directory to the new server and tried an import,
which failed with svn: Expected version '3' of repository; found version
'5'.  In fact, it says that no matter what svn command I put in.

I am running svn, version 1.1.4 (r13838)


The current version of svn is 1.7.3... sounds like you installed a much 
*older* version of svn on the new server. The error message means that 
the repo is for a newer version of svn. Either install svn 1.7.3, or at 
least find out what version you were running before, and install the 
same version. (But I'd recommend installing 1.7.3).


--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Merge shows conflicts on files that didn't change? (was Re: Question about merging)

[Dave Huang]

I guess it's time for my ~yearly question about why SVN can never seem 
to do this merge properly... Summary: I have a releaseA branch off of 
trunk, then a releaseA + custom stuff branch off of releaseA. I also 
have a releaseB branch off of trunk. I want to merge custom stuff 
into releaseB to create a releaseB + custom stuff branch, but SVN is 
showing a ton of updates/conflicts, even though custom stuff only 
touches a handful of files (as confirmed by a diff between releaseA 
and releaseA + custom stuff).


See the thread starting at 
http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3C3852DC49-BC93-45AB-A22E-1F5391257C49%40azeotrope.org%3E 
for more info.


I just tried this again with SVN 1.7.2 on the client and 1.6.15 on the 
server, and it still doesn't work right.


On 9/17/2010 2:07 PM, David Huang wrote:

On Sep 17, 2010, at 12:38 PM, Bob Archer wrote:

It is updating/writing merge info on those child nodes. There must have been a 
merge that was done at a level lower than the root folder of your project which 
put merge info on those files but not on the parent root folder.

A more concrete example:

hexley-wl:~ khym$ svn co https://my.repo/svn/branches/dave-calendar72
[ ... ]
hexley-wl:~ khym$ cd dave-calendar72
hexley-wl:dave-calendar72 khym$ svn merge --accept postpone 
https://my.repo/svn/branches/7.1@28161 
https://my.repo/svn/branches/dave-calendar71
--- Merging differences between repository URLs into '.':
[ ... ]
ULoadDB/LoadDB.cpp
[ ... ]
CReports/Invoice.rpt
[ ... ]
Summary of conflicts:
   Text conflicts: 491
   Tree conflicts: 5

# So, a .cpp was supposedly updated, and an .rpt was supposedly conflicted
hexley-wl:dave-calendar72 khym$ svn proplist 
https://my.repo/svn/branches/7.1/LoadDB/LoadDB.cpp@28161 
https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp LoadDB/LoadDB.cpp
Properties on 'https://my.repo/svn/branches/7.1/LoadDB/LoadDB.cpp':
   svn:keywords
Properties on 'https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp':
   svn:keywords
Properties on 'LoadDB/LoadDB.cpp':
   svn:keywords

# No mergeinfo on that file, in any of the places that are involved in the 
merge. Doing the same thing for Invoice.rpt shows that the only property is 
svn:mime-type.

hexley-wl:dave-calendar72 khym$ svn diff 
https://my.repo/svn/branches/7.1/LoadDB/LoadDB.cpp@28161 
https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp
hexley-wl:dave-calendar72 khym$ svn diff 
https://my.repo/svn/branches/7.1/Reports/Invoice.rpt@28161 
https://my.repo/svn/branches/dave-calendar71/Reports/Invoice.rpt

# And svn diff shows that there are neither any text differences or property 
differences.

hexley-wl:dave-calendar72 khym$ svn stat LoadDB/LoadDB.cpp Reports/Invoice.rpt
C   Reports/Invoice.rpt

# Finally, svn stat shows that there are no modifications to my WC's 
LoadDB.cpp, despite the merge supposedly updating it. However, Invoice.rpt 
really is conflicted.




--
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Subversion Exception

[Dave Huang]

On Jan 16, 2012, at 6:18 AM, Sidewinder wrote:
 Am 16.01.2012 09:05, schrieb Ulrich Eckhardt:
 I'd say that should be http://... instead of http:/..., but SVN
 shouldn't choke on that.
 
 Indeed using this syntax does crash TortoiseSVN, confirmed with 1.7.4.
 
 10287464, please take the time to report this on the TortoiseSVN mailing
 list: us...@tortoisesvn.tigris.org

Actually, the error message specifically states that it should be reported to 
the Subversion mailing list--it's an assertion failure in the SVN library.

-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: First Hands-on Subversion—Where/How?

[Dave Huang]

On Oct 28, 2011, at 5:52 PM, Pietro Moras wrote:

  more specific questions 
 
 My pleasure, dear Geoff,
Here you have some very Specific Questions.
 
 SQ1] How to get what I presume is a nice Subversion prompt: 
 
 $
 
 on one of my standard Windows machines, so to test the wonderful Subversion 
 commands so eloquently described by the mentioned self-declared Official 
 Guide and Reference Manual, so practically useless at the very beginning of a 
 learning process; that is, exactly when you need most practical and effective 
 information and support?

I think the idea of the book is that it's a guide on how to *use* Subversion, 
not a guide on how to *get* it. As a parallel, books on how to use MS Word 
don't tell you on page 1 that the first step is to visit your favorite software 
retailer and purchase a copy of Word--they assume that you already have Word 
installed.

 SQ2] Why should I go scrabbling and begging via Google for practical, 
 operative info, I'd reasonably expected to find right away at page 1 on the 
 mentioned book, or at the page 1 on the Subversion web site?

It is one the figurative page 1 of the Subversion web site. The navigation menu 
on the left side of http://subversion.apache.org/ has a Getting Subversion 
section. Click the Binary Packages link, then the Windows link, then choose any 
of the packages that are listed.

 
 SQ3] Am I the first Subversion potential user starting from scratch? 
Everybody else knowing how to set-up a Subversion environment even before 
 beginning to use it?

The documentation has instructions on how to set up a Subversion environment.

Re: Help! Subversion Exception!

[Dave Huang]

On Oct 20, 2011, at 2:03 PM, Les Mikesell wrote:
 No, I'm just being difficult because you didn't seem to care about the
 potential for losing uncommitted changes.

Why would you lose them? The upgrade process doesn't delete or modify your 
files, right? It only changes the contents of the .svn dir.

As has been posted (I don't remember which thread; probably not this one, but 
in one of the numerous threads about this issue), you can just use some sort of 
diff utility to copy your uncommitted changes to a clean checkout. If you don't 
have any uncommitted deletes, you could even just delete all .svn dirs in your 
broken WC, then copy what's left on top of the fresh WC. Something to the 
effect of:

cd $broken_wc; find . -name .svn | xargs rm -r; pax -rw . $fresh_wc

(untested, but you get the idea)
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Apache SVN Repo upgrade to 1.7.0?

[Dave Huang]

On 10/11/2011 1:03 PM, Pablo Beltran wrote:


But the bottom of the page displays this message: Powered by 
Subversion http://subversion.tigris.org/ version 1.6.17 (r1128011). 


Which page is that? The bottom of 
http://svn.apache.org/repos/asf/subversion/trunk/subversion/ says, 
Powered by Apache Subversion http://subversion.apache.org/ version 
1.7.0-rc4 (Release Candidate 4).

Re: Subversion encountered a serious problem. error details

[Dave Huang]

On Sep 28, 2011, at 11:02 AM, Jason Holland wrote:

 I am not mislead by nor do I not understand any of the errors.  The sole 
 purpose of that email was to provide feedback and details as requested by the 
 error message.

Call it what you will, but the second error message did not instruct you to 
send that error to the mailing list, nor did it imply that your Tortoise app 
is not supported by the subversion server software. The message said that, 
Subversion detected an unsupported working copy version while checking the 
status of 'C:\SourceCode\HaccpReportingSystem\trunk'. Most likely you upgraded 
another Subversion client (e.g. TortoiseSVN or the SVN client) to a newer 
version without upgrading your AnkhSVN. Please visit http://ankhsvn.net/ to 
find out about newer AnkhSVN versions supporting this Working Copy.

If you were incorrectly lead (i.e., mislead) to believe that the error message 
was telling you that your Tortoise app was not supported by the subversion 
server software, perhaps you could let us know why, and how the message could 
be improved.

Re: Subversion encountered a serious problem. error details

[Dave Huang]

On Sep 28, 2011, at 12:16 PM, Jason Holland wrote:

 Dave,
 
 Purpose of the original email was to report the error message, which is the 
 first screen shot, as was explicitly requested in the error message. 
 
 Purpose was not to discuss second error message.  Second error message was 
 included just to provide any additional details that may be of help.

That's fine, but you claimed that the second error message meant that your 
Tortoise app is not supported by the subversion server software. However, 
that is not what it's trying to tell you. If you were mislead by the message, 
perhaps you could suggest how to improve it. What it's trying to tell you is 
that most likely you upgraded another Subversion client (e.g. TortoiseSVN or 
the SVN client) to a newer version without upgrading your AnkhSVN. And that you 
could visit http://ankhsvn.net/ to find out about newer AnkhSVN versions 
supporting this Working Copy.

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Dave Huang]

On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
 convset looks to be corrupt, that value is way bigger than the other
 pointer values.  It looks like ASCII, -ftu-nvs, but that probably
 just means it's random.

It's byte-reversed svn-utf-
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

assertion failed (svn_dirent_is_absolute(local_abspath)) in SVN 1.7 beta

[Dave Huang]

Using TortoiseSVN 1.7.0 beta 2 on WinXP SP3:

TortoiseSVN 1.6.99, Build 21735 - 32 Bit , 2011/07/28 20:35:52
Subversion 1.7.0, -dev
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0d 8 Feb 2011
zlib 1.2.5)

I was in the middle of merging a few revisions from trunk to a branch (using 
the Merge a range of revisions option), got conflicts on two files and 
resolved them using TortoiseMerge, then clicking on the Resolved button. I 
then got a conflict on a third file, resolved that in TortoiseMerge, but after 
I exited TortoiseMerge and clicked on the Resolved button, I got the 
following assertion failure:

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following:

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\subversion\subversion\libsvn_wc\wc_db.c'
 line 1481: assertion failed (svn_dirent_is_absolute(local_abspath))
---
OK   
---

-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: 1.7 alpha3 bug (assert/exception) during update

[Dave Huang]

On 7/19/2011 7:15 PM, Mark Phippard wrote:
CollabNet did not post anything.  In an open-source project (mine), on 
a hosting site operated by CollabNet, I posted my Windows binaries in 
a listing labelled Development Builds just as I have been doing from 
trunk for months.  This is not different than TortoiseSVN, Subclipse 
or AnkhSVN which all post nightly builds so people can try our 
software.  I did not post the source tarball, I posted my build of the 
Windows binaries and I will likely continue to do so as the branch 
progresses towards release.


I think the concern is that it was named beta1, when the Subversion 
project hadn't announced any beta1. TSVN and AnkhSVN nightly builds 
just have version/revision numbers, without any sort of alpha/beta 
designation--e.g., TortoiseSVN-1.6.99.21696-dev-x64-svn-1.7.0-dev.msi 
or AnkhSvn-Daily-2.3.10315.msi

Re: Subversion: via Apache

[Dave Huang]

On 7/18/2011 3:43 AM, Andy Canfield wrote:


On 07/18/2011 09:34 AM, Geoff Hoffman wrote:
Test your config with -t 


Option -t on what command line? -t for svnserve means tunnel; 
svnadmin and svn have no -t option.

This thread is about Subversion: via Apache, so the Apache commandline :)

Usage: httpd [-D name] [-d directory] [-f file]
 [-C directive] [-c directive]
 [-k start|restart|graceful|graceful-stop|stop]
 [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S]
Options:
[...]
  -t : run syntax check for config files

Re: Win7 Integartion issue

[Dave Huang]

On 4/27/2010 12:09 PM, Bharti, Brijender wrote:

Hi,

I was using SVN on WinXP and migrated to Win7 64bit. I downloaded SVN
64bit (earlier was 32bit) 1.6.11. It gets installed but it does not get
integrated with Windows Explorer. I can not see Tortoise SVN also in
Program Menu. I can see it is installed in control panel and Program Folder.


It sounds like you downloaded SVN, not TortoiseSVN, since there is no 
TortoiseSVN 1.6.11 yet. The latest version of TortoiseSVN is 1.6.8.

Re: Question about excessive mergeinfo

[Dave Huang]

On 1/9/2010 11:36 AM, David Huang wrote:


On Jan 9, 2010, at 7:58 AM, Geoff Rowell wrote:

I follow a few rules to avoid this:
1) Remove obsolete merge info as part of the branch creation process
(svn pd -R svn:mergeinfo /my/branch).


I don't do that regularly (but have done it once or twice), but from my understanding, 
that fixes the problem/annoyance where existing subtree mergeinfo gets 
updated every time a merge is done, even if the merge doesn't affect the files with 
mergeinfo. That's not the same issue as what I'm seeing though; in my case, mergeinfo is 
being created on files that didn't have it before.


FWIW, I made a backup of my repo, then in the backup, removed all mergeinfo 
from trunk and made a new branch off of trunk. I confirmed that the branch 
also has no mergeinfo. I then made a commit to the trunk and merged that 
commit to the branch. It caused the same problem where mergeinfo was added 
to every file in those 4 directories that have externals.


As a second test, I removed all the external definitions from trunk, made 
yet another branch off of trunk, committed a change to trunk, then merged 
the change to the branch. Mergeinfo was created on the root of the branch, 
but nowhere else--which is what I wanted and expected.


So, it seems to have something to do with the externals, but I don't know what.