date:20120731

Re: SVN + Shadow Copy

2012-07-31 Thread Mat Booth

On 30 July 2012 20:52, Fernando Gomes  wrote:
> Hello all,
>
> I am a rather experienced developer and I’m currently trying to use SVN to 
> back up a batch of files automatically every X hours. The problem is that 
> some of the files are open and the commit fails entirely.
> I have managed to invoke a non-persistent Shadow Copy over the volume but 
> since I am not using a windows server but windows 7 the shadow copy is 
> read-only. (I am using the vscsc.exe variant of the Shadow Copy SDK from 
> Microsoft).
>
> Everything would work just fine if this Shadow Copy was write-enabled because 
> the .svn folder files cannot be edited and because so the script (running 
> "svn add" or "svn commit") cannot complete.
>
> Has anyone tried this scenario before? If so is there any way to invoke a 
> simple "svn commit" over open files (using shadow copy or not) on an 
> non-server based operating system?
>
> Thank you for any thoughts,
>
> Fernando M. A. Gomes
>


Subversion is not a backup system. Usually you would arrange for a
separate system to backup your Subversion repositories.

I can't help feeling there is a better tool out there for your use-case.

-- 
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com

Re: SVN + Shadow Copy

2012-07-31 Thread Nico Kadel-Garcia

On Tue, Jul 31, 2012 at 5:31 AM, Mat Booth  wrote:
> On 30 July 2012 20:52, Fernando Gomes  wrote:
>> Hello all,
>>
>> I am a rather experienced developer and I’m currently trying to use SVN to 
>> back up a batch of files automatically every X hours. The problem is that 
>> some of the files are open and the commit fails entirely.
>> I have managed to invoke a non-persistent Shadow Copy over the volume but 
>> since I am not using a windows server but windows 7 the shadow copy is 
>> read-only. (I am using the vscsc.exe variant of the Shadow Copy SDK from 
>> Microsoft).
>>
>> Everything would work just fine if this Shadow Copy was write-enabled 
>> because the .svn folder files cannot be edited and because so the script 
>> (running "svn add" or "svn commit") cannot complete.
>>
>> Has anyone tried this scenario before? If so is there any way to invoke a 
>> simple "svn commit" over open files (using shadow copy or not) on an 
>> non-server based operating system?
>>
>> Thank you for any thoughts,
>>
>> Fernando M. A. Gomes
>>
>
>
> Subversion is not a backup system. Usually you would arrange for a
> separate system to backup your Subversion repositories.
>
> I can't help feeling there is a better tool out there for your use-case.

Matt, it looks like he wants to back up working copies, not
repositories. Fernando, if you can leave the working copy somewhere
else and shadow copy your relevant source material to *that*, I think
you'd be in better shape.

"Files being open" and thus unable to be copied is a typical Windows
problem in an ative system. It's potentially exacerbated if you use
svn:keywords, and the files are expected to be edited dynamically when
committted.

It's an interesting problem, and understandable. For pure backup,
rather than long-term source control, I've used rsnapshot and variants
of it. And for snapshotting Windows based filesystems I've made sure
to export them via CIFS and expose them via a more sane filesystem
structure. I don't necessarily get to copy those locked files, but it
doesn't block the whole backup procedure.

Re: svnsync: E160013

2012-07-31 Thread Wagner Daniel

Hi,

I use standard post-commit and post-revprop-change hooks as described in svn
book.

post-revprop-change.cmd:
@ECHO OFF

SET REPOS="%1"
SET REV="%2"
SET USER="%3"
SET PROPNAME="%4"
SET ACTION="%5"

"%VISUALSVN_SERVER%"bin\svnsync copy-revprops --non-interactive
--source-username subversion_svc --sync-username subversion_svc
http://svn-k/svn/VTRSTCIT %REV%

post-commit.cmd:
@ECHO OFF

SET REPOS="%1"
SET REV="%2"

"%VISUALSVN_SERVER%"bin\svnsync sync --non-interactive --source-username
subversion_svc --sync-username subversion_svc http://svn-k/svn/VTRSTCIT

I've initialized the auth cache initially by passing the password at the
command line, so authorization shouldn't be an issue.

Iniial sync was done in a two-way approach due to the size of the repository.
1. svnadmin hotcopy \\server1\d$\Subversion\Repositories\VTRSTCIT
\\server2\d$\Subversion\Repositories\VTRSTCIT
2. svnsync initialize --allow-non-empty --source-username subversion_svc
--sync-username subversion_svc http://svn-k/svn/VTRSTCIT
https://svn/svn/VTRSTCIT

Regarding the errors on svn update - I could clarify that only svn commit
produces errors under yet unknown circumstances.

lG
Daniel Wagner

-Ursprüngliche Nachricht-
Von: Wagner Daniel
Gesendet: Montag, 30. Juli 2012 14:34
An: 'users@subversion.apache.org'
Betreff: svnsync: E160013

Dear all,

My users often get errors like this one when performing svn operations like
commit or update.

Error: post-commit hook failed (exit code 1) with output:
Error: svnsync: E160013:
'/svn/VTRSTCIT/!svn/txr/4174-387/BusinessObjects/Reports/ENDUR/ENDUR_Controlling/ICE_CO2_%20Bewertung_nach_Portfolio_und_Lieferjahr_+2012.rep'
path not found

We use VisualSVN 2.5.5 which includes Subversion 1.7.5 on Windows 2008 R2
running behind an IIS 7.5 as reverse-proxy, the mirror server uses the same
versions of the software. Clients use TortoiseSVN 1.7.7.

It seems that the commit was successful on the main subversion server but
svnsync isn't able to sync because the version of the mirror repository is
behind the master repository.

Any ideas how to solve this?

Regards,
Daniel

Re: SVN + Shadow Copy

2012-07-31 Thread Mat Booth

On 31 July 2012 11:01, Nico Kadel-Garcia  wrote:
> On Tue, Jul 31, 2012 at 5:31 AM, Mat Booth  wrote:
>> On 30 July 2012 20:52, Fernando Gomes  wrote:
>>> Hello all,
>>>
>>> I am a rather experienced developer and I’m currently trying to use SVN to 
>>> back up a batch of files automatically every X hours. The problem is that 
>>> some of the files are open and the commit fails entirely.
>>> I have managed to invoke a non-persistent Shadow Copy over the volume but 
>>> since I am not using a windows server but windows 7 the shadow copy is 
>>> read-only. (I am using the vscsc.exe variant of the Shadow Copy SDK from 
>>> Microsoft).
>>>
>>> Everything would work just fine if this Shadow Copy was write-enabled 
>>> because the .svn folder files cannot be edited and because so the script 
>>> (running "svn add" or "svn commit") cannot complete.
>>>
>>> Has anyone tried this scenario before? If so is there any way to invoke a 
>>> simple "svn commit" over open files (using shadow copy or not) on an 
>>> non-server based operating system?
>>>
>>> Thank you for any thoughts,
>>>
>>> Fernando M. A. Gomes
>>>
>>
>>
>> Subversion is not a backup system. Usually you would arrange for a
>> separate system to backup your Subversion repositories.
>>
>> I can't help feeling there is a better tool out there for your use-case.
>
> Matt, it looks like he wants to back up working copies, not
> repositories.

Exactly, but as I've said Subversion itself isn't a backup system and
shouldn't really be used as such.

> Fernando, if you can leave the working copy somewhere
> else and shadow copy your relevant source material to *that*, I think
> you'd be in better shape.
>
> "Files being open" and thus unable to be copied is a typical Windows
> problem in an ative system. It's potentially exacerbated if you use
> svn:keywords, and the files are expected to be edited dynamically when
> committted.
>
> It's an interesting problem, and understandable. For pure backup,
> rather than long-term source control, I've used rsnapshot and variants
> of it. And for snapshotting Windows based filesystems I've made sure
> to export them via CIFS and expose them via a more sane filesystem
> structure. I don't necessarily get to copy those locked files, but it
> doesn't block the whole backup procedure.



-- 
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com

Re: svnsync: E160013

2012-07-31 Thread Thorsten Schöning

Guten Tag Wagner Daniel,
am Dienstag, 31. Juli 2012 um 12:49 schrieben Sie:

> Regarding the errors on svn update - I could clarify that only svn
> commit produces errors under yet unknown circumstances.

I had a second look at your path:

> '/svn/VTRSTCIT/!svn/txr/4174-387/BusinessObjects/Reports/ENDUR/ENDUR_Controlling/ICE_CO2_%20Bewertung_nach_Portfolio_und_Lieferjahr_+2012.rep'
>  path not found

Could you try to reproduce the error with different file names,
especially with and without the space in front of Bewertung and the +
in front of 2012? It may not be relevant here but in CGI environments
+ may or may not be interpreted as spaces, depending on libs etc.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: SVN + Shadow Copy

2012-07-31 Thread Nico Kadel-Garcia

On Tue, Jul 31, 2012 at 6:55 AM, Mat Booth  wrote:
> On 31 July 2012 11:01, Nico Kadel-Garcia  wrote:
>> On Tue, Jul 31, 2012 at 5:31 AM, Mat Booth  wrote:
>>> On 30 July 2012 20:52, Fernando Gomes  
>>> wrote:
 Hello all,

 I am a rather experienced developer and I’m currently trying to use SVN to 
 back up a batch of files automatically every X hours. The problem is that 
 some of the files are open and the commit fails entirely.
 I have managed to invoke a non-persistent Shadow Copy over the volume but 
 since I am not using a windows server but windows 7 the shadow copy is 
 read-only. (I am using the vscsc.exe variant of the Shadow Copy SDK from 
 Microsoft).

 Everything would work just fine if this Shadow Copy was write-enabled 
 because the .svn folder files cannot be edited and because so the script 
 (running "svn add" or "svn commit") cannot complete.

 Has anyone tried this scenario before? If so is there any way to invoke a 
 simple "svn commit" over open files (using shadow copy or not) on an 
 non-server based operating system?

 Thank you for any thoughts,

 Fernando M. A. Gomes

>>>
>>>
>>> Subversion is not a backup system. Usually you would arrange for a
>>> separate system to backup your Subversion repositories.
>>>
>>> I can't help feeling there is a better tool out there for your use-case.
>>
>> Matt, it looks like he wants to back up working copies, not
>> repositories.
>
> Exactly, but as I've said Subversion itself isn't a backup system and
> shouldn't really be used as such.

Well, no, it's not. But an automated, frequent commit process is
invaluable in certain types of production environments. DNS, for
example, can really benefit from a frequent commit process and logs of
when changes were recorded.

Re: Issue with merge/integration algorithm?

2012-07-31 Thread Stefan Sperling

On Fri, Jul 27, 2012 at 08:03:22AM -0700, Arunmozhi wrote:
> 
> I am resending the initial mail as the mail format other than text is not 
> supported.
> 
> I feel that the SVN branching and merging/integration algorithm is 
> flawed. However I am not sure if this is a known limitation of SVN. I 
> did 2 tests to compare SVN against Perforce/git. The intention of the test 
> is to see if a change done by a user at some point in time and taken to 
> multiple branches comes back to the main branch duplicated multiple 
> times without indicating a conflict.
> 
> Please look into the attached tests.txt. Each column shows the contents of a 
> file as we
> do successive changes to the file.  Also please refer below the explanatory 
> steps.
> 
> I use tortoisesvn 1.7.5 as the user interface and hence I can just list 
> 
> the menu commands corresponding to each step and not the exact SVN 
> commands (I am not used to the command line). The following are the 
> steps I executed for Test 1.
> 
> (1) Create a file myfile.txt with following contents and add it to the 
> repository (TortoiseSVN -> Add, SVN Commit).
> a
> b
> c
> z
> 
> (2) Branch the file myfile.txt to a new location (TortoiseSVN -> Branch/Tag 
> (From:myfile.txt To:branch1/myfile.txt), SVN update). Now the contents 
> of branch1/myfile.txt is
> a
> b
> c
> z
> 
> (3) Edit the branch1/myfile.txt by inserting a line 'd' as follows and then 
> commit the changes (SVN Commit). Now the contents of branch1/myfile.txt is
> a
> b
> c
> d
> z
> 
> (4) Now branch the file branch1/myfile.txt to branch2/myfile.txt (TortoiseSVN 
> -> Branch/Tag (From:branch1/myfile.txt To:branch2/myfile.txt), SVN update). 
> Now the contents of branch2/myfile.txt is
> a
> b
> c
> d
> z
> 
> (5) Now edit the file branch2/myfile.txt by changing the 'c' to 'x' and 
> then commit the changes (SVN commit). Now the contents of branch2/myfile.txt 
> is
> a
> b
> x
> d
> z
> 
> (6) Now integrate the branch1/myfile.txt back to myfile.txt (TortoiseSVN 
> -> Merge (Reintegrate a branch From:branch1/myfile.txt To working 
> copy:myfile.txt), SVN commit). Now the contents of myfile.txt is
> a
> b
> c
> d
> z
> 
> (7) Now integrate the branch2/myfile.txt back to myfile.txt (TortoiseSVN -> 
> Merge (Reintegrate a branch From:branch2/myfile.txt To working 
> copy:myfile.txt), SVN commit). Now the contents of myfile.txt is
> a
> b
> x
> d
> d
> z
> 
> You can see that the line 'd' appears twice in the integrated file. 'd' is 
> inserted only once in the revision history. The expected output 
> (verified in perforce and git) is
> a
> b
> x
> d
> z

Yes, I can see the problem now, thanks.

I suppose it depends on the way Subversion selects a common ancestor to
use as merge base. Git, perforce and svn internally all use the diff3
algorithm to perform file merges. The result of that algorithm depends
on the set of input files, often called "base", "merge-left", "merge-right",
where the merge-left and merge-right version of the file are both derived
from the same "base" file. Subversion's selection of the common ancestor
(the "base") is affected by mergeinfo. The order in which merges are
performed matters since it affects merge-tracking information present
during the final merge.

If you reintegrate branch2/myfile.txt into branch1/myfile.txt first,
and then reintegrate branch1/myfile.txt to /myfile.txt, the result
of the last merge is the same as with git and perforce:

$ svn diff
Index: myfile.txt
===
--- myfile.txt  (revision 7)
+++ myfile.txt  (working copy)
@@ -1,4 +1,5 @@
 a
 b
-c
+x
+d
 z

If you want to understand in more detail how Subversion's merges behaves
I'd recommend reading http://wiki.apache.org/subversion/SymmetricMerge

Git and perforce perform merge-tracking in a different way, and might
always select the same common ancestor independently of the order merges
are performed in.

Re: FeatureRequest: Improved svn:externals handling on Merge

2012-07-31 Thread Stefan Sperling

On Mon, Jul 30, 2012 at 10:13:37AM +0100, Marcel Hesselbarth wrote:
> Hi Developers,
> 
> I'm redirected here from the tortoise mailing list, as they think this
> feature belongs to the area of the svn library. Performing some
> searches shows that I'm not the only one with this problem, even it it
> seems to be never posted here.
> 
> The basic problem I have is I have a Project with svn:externals 
> defined pointing into the same SVN. When I now make a tortoiseSVN 
> commit the files changed inside the svn:externals folders are included 
> - so all works great.
> 
> If I now try to merge these commit into a other checkout the changes 
> inside the svn:externals are not merged, they are silently ignored. I 
> need to do a separate merge at the svn:externals folders. Doing so 
> works fine, but why having to do this manually? As externals are 
> silently included into commits it is easily overseen that a commit 
> includes externals at merging. So if these externals are not merged or 
> at least warned while merging they will be overseen -> an great source 
> for new bugs...
> 
> The merge of svn:externals is not done automatically independent of if 
> the folder at the merge target is an linked svn:externals folder or a 
> real folder.
> 
> 
> 
> Now a detailed example for better visualisation:
> I have the following svn structure:
> svn://svn/test/main/trunc
>   svn:external Propery: svn://svn/test/sub/trunc sub
>   File: Mainfile.txt
> svn://svn/test/sub/trunc Project
>   File: Subfile.txt
> 
> Now I make a branch and set the svn:external Propery:
> svn://svn/test/main/branch1
>   svn:external Propery: svn://svn/test/sub/branch1 sub
>   File: Mainfile.txt
> svn://svn/test/sub/branch1 Project
>   File: Subfile.txt
> 
> 
> On a Checkout of main Project this will result in the following file 
> structures:
>   mainTrunc
>   | Mainfile.txt
>   | sub
>   | | Subfile.txt
>   mainBranch
>   | Mainfile.txt
>   | sub
>   | | Subfile.txt
> 
> 
> If I make changes at Mainfile.txt and Subfile.txt at main in one 
> commit with version 123. To merge these changes to the branch I have 
> to do the following:
> 1. Go to mainBranch folder an merge svn://svn/test/main/trunc version 123
> 2. Go to mainBranch/sub folder and merge svn://svn/test/sub/trunc version 123
> All information required for the 2. merge of the externals folder is 
> already known by the tortoise client. It knows there are files at the 
> svn://svn/test/sub/trunc folder included at these commit and it knows 
> these files are loyally stored at mainBranch/sub folder.
> 
> 
> 
> With best regards,
>   Marcel Hesselbarth
> 

This is a known and documented issue with externals.

The Subversion book says this on the topic:

Perhaps most disappointingly, the working copies created via the externals
definition support are still disconnected from the primary working copy (on
whose versioned directories the svn:externals property was actually set). And
Subversion still truly operates only on nondisjoint working copies. So, for
example, if you want to commit changes that you've made in one or more of those
external working copies, you must run svn commit explicitly on those working
copies—committing on the primary working copy will not recurse into any
external ones.
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

There are reasons for not committing from externals by default.
For example, you might not have commit privileges for the repository
an externals is pointing at. If Subversion tried to commit to that
repository every time you make a commit that would be rather annoying.

That said, we're trying to lift some of these limitations with externals.
In particular, there will be a new --include-externals option for 'svn
commit' in Subversion 1.8. This option causes recursive commit from the
parent working copy as well as all externals within the working copy.

It might be possible to add this option to 'svn merge' as well, to address
your particular use case. You'd have to run a merge with --include-externals
to tell Subversion "please consider the externals in my working copy
as part of the merge target". I think this is a valid feature request
and if you like you can open a new ENHANCEMENT issue (see 
http://subversion.apache.org/reporting-issues.html for more information)
and name me as your bug buddy.

However it is probably not as trivial to implement as it sounds.
I would guess that this task would make a nice google summer of code
project, i.e. somebody with little or no prior experience with Subversion's
code base would probably need about 3 months to get this feature
implemented in a quality worth releasing. Maybe you know an intern
or student who would like to help? :)

Re: Subversion authentication via SASL GSSAPI and likewise open

2012-07-31 Thread slaventii

Want to share some of my tests results:
/trunk - 1.80 GB (1,941,844,940 bytes) - 148,114 Files; 52,519 Folders

Old Hardware Server - Ubuntu 9.04:
 svn, version 1.5.4 (r33841) compiled Aug  7 2009, 01:44:11
co svn://  ~ 23m 32sec
co https:// ~ 30m 10sec
svn vs https perf, % ~ > 28%

up svn:// ~ 3m 22sec
up https:// ~ 5m 04sec
svn vs https perf, % > 50%

New Hardware Server - Ubuntu 12.04:
svn, version 1.6.17 (r1128011) compiled Dec 17 2011, 16:12:52
co svn://  ~ 18m 30sec
co https:// ~ 22m 47sec
svn vs https perf, % ~ > 23%

up svn:// ~ 2m 06sec
up https:// ~ 2m 35sec
svn vs https perf, % ~ > 23%

New Hardware Server - Ubuntu 12.04:
svn, version 1.7.5 (r1336830) compiled Jul 19 2012, 21:53:29
co svn://  ~ 22m 50sec
co https:// ~ 24m 00sec
svn vs https perf, % ~ > 5%

up svn:// ~ 2m 38sec
up https:// ~ 2m 28 sec
svn vs https perf, % ~ < 7%

I can see that in general performance didn't increase so much.
But difference between svn and http decreased.

On Thu, Jul 26, 2012 at 12:21 PM, Cooke, Mark  wrote:
>
> Note: please reply in-line and, if at all possible, in _plain_ text, not
> html...
>
>> On Thu, Jul 26, 2012 at 11:50 AM, Cooke, Mark
>>  wrote:
>>
>>   > On Thu, Jul 26, 2012 at 9:38 AM, Cooke, Mark
>>   >  wrote:
>>   >
>>   >
>>   >   > -Original Message-
>>   >   > From: xumuku [mailto:xum...@gmail.com]
>>   >   > Sent: 25 July 2012 16:49
>>   >   > To: subversion_us...@googlegroups.com
>>   >   > Cc: users@subversion.apache.org; xum...@gmail.com
>>   >   > Subject: Re: Subversion authentication via
>> SASL GSSAPI and
>>   >   > likewise open
>>   >   >
>>   >   > My current  /usr/lib/sasl2/svn.conf is:
>>   >   >
>>   >   > pwcheck_method: saslauthd
>>   >   > mech_list: GSSAPI
>>   >   > saslauthd_path: /var/run/saslauthd/mux
>>   >   > log_level: 7
>>   >   >
>>   >   > But I get the error:
>>   >   > Cannot negotiate authentication mechanism
>>   >   >
>>   >   > 1. Does *anyone* have Windows SVNServe
>> authenticating to
>>   >   > AD/Kerberos via SASL/GSSAPI?
>>   >   >
>>   > >   > windows-svnserve-authenticating-to-ad-kerberos-via-sasl-gssap>
>>   >   > 2. Cannot negotiate authentication mechanism
>>   >   >
>>   > >   > &viewType=browseAll&dsMessageId=65725#messagefocus>
>>   >
>>   >   No (sorry), we use https via apache and mod_ldap to
>>   > authenticate against AD.  I am interested to know why you
>>   > think that is not secure enough (perhaps you have *nix
>>   > clients storing plain text passwords?)
>>   >
>>   >   ~ mark c
>>   >
>>   > Because it works only with PLAIN auth:
>>
>>   Ah, ok, yes, I did say we use https.  The server is
>> configured to redirect all http traffic to https (using
>> mod_ssl) and authentication then happens in that encrypted
>> environment (or am I being naïve here?)
>>
>>   > tcpdump -ni eth0 -A src host 192.168.1.2 and tcp dst port 3690
>>   >
>>   >
>>   > 17:10:10.488834 IP 192.168.1.2.59751 > 192.168.1.1.3690:
>>   > Flags [P.], seq 145:184, ack 166, win 65115, length 39
>>   > E..O.b@"..@...@ .g.j~...P..[( PLAIN (
>>   > 21:AHVzZXIAcGFzc3dvcmQ=
>>   >
>>   >
>>   > http://www.opinionatedgeek.com/dotnet/tools/base64decode/ -
>>   > and you can see my sername and password
>>   >
>>   >
>>   > We already have Apache via mod_svn and mod_ldap but
>> it is very slow.
>>
>>   What is very slow?  I know we don't have many users and
>> are on an internal network but I have no issue with our speeds...
>>
>>   ~ mark c
>>
>> -Original Message-
>> From: slaventii [mailto:xum...@gmail.com]
>> Sent: 26 July 2012 09:58
>> To: Cooke, Mark
>> Cc: users@subversion.apache.org
>> Subject: Re: Subversion authentication via SASL GSSAPI and
>> likewise open
>>
>> >Ah, ok, yes, I did say we use https.  The server is
>> configured to redirect all http traffic >to https (using
>> mod_ssl) and authentication then happens in that encrypted
>> >environment (or am I being naïve here?)
>> As I wrote we already have Apache with HTTPS. All is good
>> except speed.
>
> Sorry, I read the list, not links to other sites.
>
>> >What is very slow?  I know we don't have many users and are
>> on an internal network >but I have no issue with our speeds...
>>
>> And this is no

Re: SVN + Shadow Copy

2012-07-31 Thread Les Mikesell

On Tue, Jul 31, 2012 at 5:55 AM, Mat Booth  wrote:
>
>> Matt, it looks like he wants to back up working copies, not
>> repositories.
>
> Exactly, but as I've said Subversion itself isn't a backup system and
> shouldn't really be used as such.

OK, but what if he had said he wanted to automate revision control of
a large set of files?   Is subversion suitable for that?

For straight backups, I like backuppc which will efficiently compress
and pool all unchanged files of the same content (even when found in
different locations), has a nice web interface for browsing and
restores, and can use rsync for efficient transfers of changes.  And
people have wrapped in volume snapshots in its pre/post backup
routines even though it is not included in the base system.  However,
it is not efficient at storing large files with small changes and does
not provide an interface for viewing differences or change history.
I'd like to find something that has that latter functionality but can
be automated to handle things like system config files with a set of
machines treated as branches.   Has anyone done this with subversion
or is there a better approach?

-- 
   Les Mikesell
  lesmikes...@gmail.com

svn log: 1.7 and large limits

2012-07-31 Thread Dmitry Pavlenko

Hi all.
I've noticed that in SVN 1.7 limit behaviour has changed. Is that expected or 
is that a bug?

As I understand subversion supports revisions up to Long.MAX_VALUE = 
0x7fffL =
9223372036854775807 > 1000 > 100

So both limits are possible thoeoretically. I ask because Java programmers 
often use Long.MAX_VALUE 
as "infinity" value instead of 0.


$ $svn16 log http://localhost:59714/repos -l 100

r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
 
 

r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
 
 

$ $svn17 log http://localhost:59714/repos -l 100
svn: E205000: Non-numeric limit argument given
svn: E24: Number '100' is out of range '[-2147483648, 2147483647]'
 
$ $svn16 log file://`pwd` -l 100

r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
 
 

r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
 
 

 
$ $svn17 log file://`pwd` -l 100
svn: E205000: Non-numeric limit argument given
svn: E24: Number '100' is out of range '[-2147483648, 2147483647]'
 
Let's now try with larger limit:
 
$ $svn16 log http://localhost:59714/repos -l 1000
svn: Argument to --limit must be positive
 
$ $svn17 log http://localhost:59714/repos -l 1000
svn: E205000: Non-numeric limit argument given
svn: E24: Number '1000' is out of range '[-2147483648, 
2147483647]'
 
$ $svn16 log file://`pwd` -l 1000
svn: Argument to --limit must be positive
 
$ $svn17 log file://`pwd` -l 1000
svn: E205000: Non-numeric limit argument given
svn: E24: Number '1000' is out of range '[-2147483648, 
2147483647]'

Re: Subversion authentication via SASL GSSAPI and likewise open

2012-07-31 Thread Johan Corveleyn

On Tue, Jul 31, 2012 at 6:59 PM, slaventii  wrote:
> Want to share some of my tests results:
> /trunk - 1.80 GB (1,941,844,940 bytes) - 148,114 Files; 52,519 Folders
> 
> Old Hardware Server - Ubuntu 9.04:
>  svn, version 1.5.4 (r33841) compiled Aug  7 2009, 01:44:11
> co svn://  ~ 23m 32sec
> co https:// ~ 30m 10sec
> svn vs https perf, % ~ > 28%
>
> up svn:// ~ 3m 22sec
> up https:// ~ 5m 04sec
> svn vs https perf, % > 50%
> 
> New Hardware Server - Ubuntu 12.04:
> svn, version 1.6.17 (r1128011) compiled Dec 17 2011, 16:12:52
> co svn://  ~ 18m 30sec
> co https:// ~ 22m 47sec
> svn vs https perf, % ~ > 23%
>
> up svn:// ~ 2m 06sec
> up https:// ~ 2m 35sec
> svn vs https perf, % ~ > 23%
> 
> New Hardware Server - Ubuntu 12.04:
> svn, version 1.7.5 (r1336830) compiled Jul 19 2012, 21:53:29
> co svn://  ~ 22m 50sec
> co https:// ~ 24m 00sec
> svn vs https perf, % ~ > 5%
>
> up svn:// ~ 2m 38sec
> up https:// ~ 2m 28 sec
> svn vs https perf, % ~ < 7%
> 
> I can see that in general performance didn't increase so much.
> But difference between svn and http decreased.

What kind of network connection between server and client?

The svn version numbers you report, are those the versions of the
server, or of the client, or both?

-- 
Johan

Re: Subversion authentication via SASL GSSAPI and likewise open

2012-07-31 Thread slaventii

Hi Johan,
Hm, it's very strange. I thought that I used 1.7.5 but it seems that
in my PATH("c:\Program Files\CollabNet Subversion Server\svn.exe" )
was old version
of client: svn, version 1.5.4 (r33841)   compiled Oct 23 2008, 08:54:42
In this case all my test were done with old client :)
Started new set of tests with "c:\Program
Files\TortoiseSVN\bin\svn.exe"  that is
svn, version 1.7.5 (r1336830) compiled May 15 2012, 12:29:08

Thank you for observation.


On Tue, Jul 31, 2012 at 9:48 PM, Johan Corveleyn  wrote:
> On Tue, Jul 31, 2012 at 6:59 PM, slaventii  wrote:
>> Want to share some of my tests results:
>> /trunk - 1.80 GB (1,941,844,940 bytes) - 148,114 Files; 52,519 Folders
>> 
>> Old Hardware Server - Ubuntu 9.04:
>>  svn, version 1.5.4 (r33841) compiled Aug  7 2009, 01:44:11
>> co svn://  ~ 23m 32sec
>> co https:// ~ 30m 10sec
>> svn vs https perf, % ~ > 28%
>>
>> up svn:// ~ 3m 22sec
>> up https:// ~ 5m 04sec
>> svn vs https perf, % > 50%
>> 
>> New Hardware Server - Ubuntu 12.04:
>> svn, version 1.6.17 (r1128011) compiled Dec 17 2011, 16:12:52
>> co svn://  ~ 18m 30sec
>> co https:// ~ 22m 47sec
>> svn vs https perf, % ~ > 23%
>>
>> up svn:// ~ 2m 06sec
>> up https:// ~ 2m 35sec
>> svn vs https perf, % ~ > 23%
>> 
>> New Hardware Server - Ubuntu 12.04:
>> svn, version 1.7.5 (r1336830) compiled Jul 19 2012, 21:53:29
>> co svn://  ~ 22m 50sec
>> co https:// ~ 24m 00sec
>> svn vs https perf, % ~ > 5%
>>
>> up svn:// ~ 2m 38sec
>> up https:// ~ 2m 28 sec
>> svn vs https perf, % ~ < 7%
>> 
>> I can see that in general performance didn't increase so much.
>> But difference between svn and http decreased.
>
> What kind of network connection between server and client?
>
> The svn version numbers you report, are those the versions of the
> server, or of the client, or both?
>
> --
> Johan

Re: svn log: 1.7 and large limits

2012-07-31 Thread Philip Martin

Dmitry Pavlenko  writes:

> Hi all.
> I've noticed that in SVN 1.7 limit behaviour has changed. Is that expected or 
> is that a bug?

> $ $svn16 log http://localhost:59714/repos -l 100
> 
> r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>  
>  
> 
> r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>  
>  
> 
> $ $svn17 log http://localhost:59714/repos -l 100
> svn: E205000: Non-numeric limit argument given
> svn: E24: Number '100' is out of range '[-2147483648, 2147483647]'

Internally Subversion always uses a 32-bit value for limit.  In 1.6 the
command line parser doesn't detect out-of-range values on the command
and any such values are silently truncated.  In 1.7 the command line
parser detects out-of-range values.

-- 
Philip

Re: svn log: 1.7 and large limits

2012-07-31 Thread Johan Corveleyn

On Tue, Jul 31, 2012 at 9:18 PM, Philip Martin
 wrote:
> Dmitry Pavlenko  writes:
>
>> Hi all.
>> I've noticed that in SVN 1.7 limit behaviour has changed. Is that expected 
>> or is that a bug?
>
>> $ $svn16 log http://localhost:59714/repos -l 100
>> 
>> r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>>
>>
>> 
>> r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>>
>>
>> 
>> $ $svn17 log http://localhost:59714/repos -l 100
>> svn: E205000: Non-numeric limit argument given
>> svn: E24: Number '100' is out of range '[-2147483648, 
>> 2147483647]'
>
> Internally Subversion always uses a 32-bit value for limit.  In 1.6 the
> command line parser doesn't detect out-of-range values on the command
> and any such values are silently truncated.  In 1.7 the command line
> parser detects out-of-range values.

Also slightly related, this recent discussion on dev@:

http://svn.haxx.se/dev/archive-2012-06/0263.shtml

-- 
Johan

Re: svn log: 1.7 and large limits

2012-07-31 Thread Stefan Sperling

On Tue, Jul 31, 2012 at 08:44:18PM +0200, Dmitry Pavlenko wrote:
> Hi all.
> I've noticed that in SVN 1.7 limit behaviour has changed. Is that expected or 
> is that a bug?
> 
> As I understand subversion supports revisions up to Long.MAX_VALUE = 
> 0x7fffL =
> 9223372036854775807 > 1000 > 100
> 
> So both limits are possible thoeoretically. I ask because Java programmers 
> often use Long.MAX_VALUE 
> as "infinity" value instead of 0.

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.

> $ $svn16 log http://localhost:59714/repos -l 100
> 
> r2 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>  
>  
> 
> r1 | (no author) | 2012-07-11 13:15:58 +0200 (Срд, 11 Июл 2012) | 1 line
>  

The 1.6 code uses strtol() without checking for overflow errors.
In the above case the large value you pass overflows and produces
some positive number within the range '[0, 2147483647]'.
Thus the limit is not 100 (as you expect) but some other value.

> 
> $ $svn17 log http://localhost:59714/repos -l 100
> svn: E205000: Non-numeric limit argument given
> svn: E24: Number '100' is out of range '[-2147483648, 2147483647]'

The 1.7 code uses the new-in-1.7 helper function svn_cstring_to_atoi()
to convert the limit argument from a string into an 'int' variable.
This function refuses to convert a string to a number if the string
does not encode a number within the range an 'int' can represent,
i.e. it checks for overflow errors and non-numeric character strings.

> Let's now try with larger limit:
>  
> $ $svn16 log http://localhost:59714/repos -l 1000
> svn: Argument to --limit must be positive

This is an example where the strtol() overflow results in some negative
number.

I would say the 1.7 behaviour is better. You either get the specified
limit or an error, never some limit based on the result of overflow.
But I'm the person who made this change so I'm obviously biased :)

Re: SOLVED: "svn: Authorization failed"; what am I doing wrong?

2012-07-31 Thread valve79


Have the same problem but im running ubuntu, any idea where i can find this
file ? 
-- 
View this message in context: 
http://old.nabble.com/%22svn%3A-Authorization-failed%22--what-am-I-doing-wrong--tp21799403p34237492.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: svn log: 1.7 and large limits

2012-07-31 Thread 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++

Re: Subversion authentication via SASL GSSAPI and likewise open

2012-07-31 Thread slaventii

Forgot to say about network - it's LAN 100 Mbit/s.
It is very strange first test
co https:// 40m 17 sec !!!


On Tue, Jul 31, 2012 at 9:48 PM, Johan Corveleyn  wrote:
> On Tue, Jul 31, 2012 at 6:59 PM, slaventii  wrote:
>> Want to share some of my tests results:
>> /trunk - 1.80 GB (1,941,844,940 bytes) - 148,114 Files; 52,519 Folders
>> 
>> Old Hardware Server - Ubuntu 9.04:
>>  svn, version 1.5.4 (r33841) compiled Aug  7 2009, 01:44:11
>> co svn://  ~ 23m 32sec
>> co https:// ~ 30m 10sec
>> svn vs https perf, % ~ > 28%
>>
>> up svn:// ~ 3m 22sec
>> up https:// ~ 5m 04sec
>> svn vs https perf, % > 50%
>> 
>> New Hardware Server - Ubuntu 12.04:
>> svn, version 1.6.17 (r1128011) compiled Dec 17 2011, 16:12:52
>> co svn://  ~ 18m 30sec
>> co https:// ~ 22m 47sec
>> svn vs https perf, % ~ > 23%
>>
>> up svn:// ~ 2m 06sec
>> up https:// ~ 2m 35sec
>> svn vs https perf, % ~ > 23%
>> 
>> New Hardware Server - Ubuntu 12.04:
>> svn, version 1.7.5 (r1336830) compiled Jul 19 2012, 21:53:29
>> co svn://  ~ 22m 50sec
>> co https:// ~ 24m 00sec
>> svn vs https perf, % ~ > 5%
>>
>> up svn:// ~ 2m 38sec
>> up https:// ~ 2m 28 sec
>> svn vs https perf, % ~ < 7%
>> 
>> I can see that in general performance didn't increase so much.
>> But difference between svn and http decreased.
>
> What kind of network connection between server and client?
>
> The svn version numbers you report, are those the versions of the
> server, or of the client, or both?
>
> --
> Johan

SVNSYNC Error

2012-07-31 Thread Honeylyn O. Fukuoka

Hi,



I have to sync our repository to another server, so to test it, I created a
test repository in my local and tried to do svnsync command to sync/mirror
it.

Here's what I did:



1. Go to the folder where the repositories are located

2. in the cmd typed: svnsync initialize (URL of the Repository to Mirror)
(URL of the Destination of the Mirrored Repo)

  sample:  svnsync initialize svn://loocalhost/Repo Name
svn://localhost/Destination Repo Name



ERROR:

svnsync: E16506: Repository has not been eabled to accept revision
propchanges; ask the administrator to create a pre-revprop-change hook.



I am using Subvrsion Sever 1.7.5



Question:

1. Am I on the right path in creating the Mirror Repository?

2. How do I create a pre-revprop-change hook? I tried some hooks that I saw
in the search engine but didn't work.





Please help me on this.







Thanks so much,

-- 
*HONEYLYN O. FUKUOKA*
System Administrator
Menue Philippines, Inc.
*
*

44 matches

Mail list logo