RE: Tigris binary packages for Windows

[Cooke, Mark]

Dear list,

> > Troy Simpson wrote: 
> > 
> > I was advised to discuss this on the dev list, which is 
> > what I did, however there has been zero response.  There is 
> > more discussion on the user end than the developer end.  If 
> > anyone in user-land has the capability to construct the 
> > binaries in a similar fashion to the way they were produced 
> > before, I for one would bring this to the attention of the 
> > developer list if nobody else does.  It is my opinion that 
> > the project should have a 'supported' release to assist with 
> > bug finding and to provide end-users with a standard 
> > base-level release.
> > 
I cannot help thinking that we might have avoided a lot of questions and
frustrations if a status note and request for a new maintainer had been
added to either the download page (still tigris.org) and/or the Windows
Binaries page at apache
(http://subversion.apache.org/packages.html#windows).

> Olivier Sannier wrote:
>
> So the situation is as follows:
> 
> The previous builder (DJ Heap?) does not have the time to 
> build the Win32 binaries anymore.
> I, for one, could dedicate a few hours to create the latest 
> ones and the next ones as well. It does not seem too much 
> complicated to build them.
> What I'm lacking is a description of what to run and in what order.
> I mean, there are Python scripts related to win32 in the 
> build folder, but I am not sure what they are doing. Having a 
> simple "step by step" guide would actually save time.
> Is there a way to ask the previous builder to at least document this?
> 
I have looked at buiding the binaries myself but am unsure of how much
work there is (and I have issues about what I am allowed to install
here) but there seems to be quite a lot involved to build:
~ the main subversion binaries
~ Apache 2.0 binaries
~ Apache 2.2 binaries
~ python bindings for 2.5, 2.6, ...
~ ruby bindings
~ perl bindings
~ JavaHL (?)
~ Debug symbol packages

As previously mentioned, the problem stems mostly from lack of
instructions of how to put this all together...

~ Mark C

Re: SCM, Content-Management and cherry-picking in big project

[pacco]

Am 01.03.2010 20:35, schrieb Pacco:
> Hi David,
> 
> I'm very thankful about your brief response and the many ideas and 

Sorry, should of course be 'elaborated', not 'brief'.

RE: merge BASE:HEAD vs update

[Bert Huijben]

svn merge -r BASE:HEAD --dry-run

 

Does a merge from the current revision of the root of the merge (where BASE
is translated to a specific revision) to the head revision of all files and
folders below the root using mergetracking.

 

'svn update' updates each individual path from its current revision to the
HEAD revision, to make the working copies BASE represent the entire tree at
HEAD.

 

These two operations are not the same, so the results differ.

 

Under some specific circumstances the result might be similar: E.g. when the
working copy is on exactly one revision (not mixed revision).

 

The command

svn status -u

(-u is short for --show-updates)

 

Gives a better indication on what an update will retrieve, but doesn't look
at the file contents to see if you would get any textual conflicts

 

Bert Huijben

 

From: Mark Keisler [mailto:grim...@gmail.com] 
Sent: maandag 1 maart 2010 21:45
To: users@subversion.apache.org
Subject: merge BASE:HEAD vs update

 

I use svn merge -r BASE:HEAD --dry-run . to check what an update will do to
me.  Today, it predicted all kinds of trouble, but then update worked just
fine.  Why is that?

% svn merge -r BASE:HEAD --dry-run .
--- Merging r862 through r970 into 'TWiki/Plugins/ReqDocInfoPlugin.pm':
 G   TWiki/Plugins/ReqDocInfoPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins/BugzillaQueryPlugin.pm':
 G   TWiki/Plugins/BugzillaQueryPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins/ReqErrorPlugin.pm':
 G   TWiki/Plugins/ReqErrorPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins/ReqNewDocPlugin.pm':
 G   TWiki/Plugins/ReqNewDocPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins':
CTWiki/Plugins/ReqMarkupPlugin/ReqMarkupPlugin.txt
--- Merging r862 through r970 into 'TWiki/Plugins/ReqMarkupPlugin.pm':
 G   TWiki/Plugins/ReqMarkupPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins/ReqNewReqMarkupPlugin.pm':
CG   TWiki/Plugins/ReqNewReqMarkupPlugin.pm
--- Merging r862 through r970 into 'TWiki/Plugins':
 G   TWiki/Plugins
--- Merging r862 through r970 into 'TWiki/Contrib':
CTWiki/Contrib/Dude/Utilities/MyConfig.pm
   C TWiki/Contrib/Dude/RM/ExportProcessor
   C TWiki/Contrib/Dude/RM/ConfigFiles/RmReqtTemplateStrings.txt
 G   TWiki/Contrib
Summary of conflicts:
  Text conflicts: 3
  Tree conflicts: 2
% svn update
UTWiki/Plugins/ReqMarkupPlugin/ReqMarkupPlugin.txt
UTWiki/Plugins/ReqNewReqMarkupPlugin.pm
UTWiki/Contrib/Dude/Utilities/MyConfig.pm
Updated to revision 970.

-- 
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."

List of all files in conflict

[Lasse Kliemann]

Is there a reliable and direct way to get a list of all files 
that are in conflict for a particular working copy? Of course, 
one can parse the output of 'svn status' or 'svn status --xml', 
but maybe there is something like 'svn status --conflicts'?

Thank you.


pgpSAesMxlyoF.pgp
Description: PGP signature

strange problem with subversion merge

[J. Bakshi]

Dear list,

Greetings to all of you. Hope you all are well.

I have come back again to discuss on svn merge which is not working at
all here. The version running at server is


svn, version 1.5.1 (r32289)
compiled Aug 6 2009, 16:55:38
`

The client pc has


svn, version 1.6.6 (r40053)
compiled Nov 1 2009, 12:15:31
```

I have done a checkout of a repo at client and then start making trunk
and branches

[1] svn co https://192.168.1.1/repos/testrepo ./

[2] cd testrepo

svn mkdir trunk branches
svn mv folder1 folder2 folder3 trunk/
svn commit -m "creating trunk and placing files/folder in it"

till now everything is ok

[3] Now making a branch

svn copy trunk branches/mybranch
svn up

all is OK.

[4] and now merging. I have already changed
branches/mybranch/folder1/file1 and commit successfully. "svn diff -r
475:476" reports the changes I made. BUT


svn merge -r 475:476 trunk/
`

just returns null value. It should merge the changes I made at
branches/mybranch/folder1/file1 to trunk/folder1/file1. Have I missed
something ? Please suggest.

thanks


-- 
জয়দীপ বক্সী

RE: strange problem with subversion merge

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: J. Bakshi [mailto:joyd...@infoservices.in]
> Sent: 02 March 2010 11:17
> To: users@subversion.apache.org
> Subject: strange problem with subversion merge
>
> Dear list,
>
> Greetings to all of you. Hope you all are well.
>
> I have come back again to discuss on svn merge which is not
> working at all here. The version running at server is
>
> 
> svn, version 1.5.1 (r32289)
> compiled Aug 6 2009, 16:55:38
> `
>
> The client pc has
>
> 
> svn, version 1.6.6 (r40053)
> compiled Nov 1 2009, 12:15:31
> ```
>
> I have done a checkout of a repo at client and then start
> making trunk and branches
>
> [1] svn co https://192.168.1.1/repos/testrepo ./
>
> [2] cd testrepo
>
> svn mkdir trunk branches
> svn mv folder1 folder2 folder3 trunk/
> svn commit -m "creating trunk and placing files/folder in it"
>
> till now everything is ok
>
> [3] Now making a branch
>
> svn copy trunk branches/mybranch
> svn up
>
> all is OK.
>
> [4] and now merging. I have already changed
> branches/mybranch/folder1/file1 and commit successfully. "svn
> diff -r 475:476" reports the changes I made. BUT
>
> 
> svn merge -r 475:476 trunk/
> `
> just returns null value. It should merge the changes I made at
> branches/mybranch/folder1/file1 to trunk/folder1/file1. Have
> I missed something ? Please suggest.
>

I understand you want to merge the changes you have done in the branch to the 
trunk. If that's the case then from the branch you use the --reintegrate option.

The merge command you issued merges the changes between 475 and 476 done to 
trunk into the directory you are in. Since the changes happened on the branch 
it's correct that it doesn't merge anything.

Re: strange problem with subversion merge

[J. Bakshi]

On 03/02/2010 05:02 PM, Giulio Troccoli wrote:


>> 
>> svn merge -r 475:476 trunk/
>> `
>> just returns null value. It should merge the changes I made at
>> branches/mybranch/folder1/file1 to trunk/folder1/file1. Have
>> I missed something ? Please suggest.
>>
>> 


> I understand you want to merge the changes you have done in the branch to the 
> trunk. If that's the case then from the branch you use the --reintegrate 
> option.
>
> The merge command you issued merges the changes between 475 and 476 done to 
> trunk into the directory you are in. Since the changes happened on the branch 
> it's correct that it doesn't merge anything.
>
>   


Hello,

Thanks a lot for your response. I am afraid but I am not fully
understand the logic. Which I am following is collected from net and I
have just doing the same. I admit I don't know the in-depth about how
merging works. It might be interesting that I am now getting something
new than the empty return as before. Please fine below

``
svn diff -r 488:489
Index: branches/bug/typo3conf/localconf.php
===
--- branches/bug/typo3conf/localconf.php (revision 488)
+++ branches/bug/typo3conf/localconf.php (revision 489)
@@ -1,9 +1,12 @@

RE: strange problem with subversion merge

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: J. Bakshi [mailto:joyd...@infoservices.in]
> Sent: 02 March 2010 11:56
> To: Giulio Troccoli
> Cc: users@subversion.apache.org
> Subject: Re: strange problem with subversion merge
>
> On 03/02/2010 05:02 PM, Giulio Troccoli wrote:
>
> 
> >> 
> >> svn merge -r 475:476 trunk/
> >> `
> >> just returns null value. It should merge the changes I made at
> >> branches/mybranch/folder1/file1 to trunk/folder1/file1.
> Have I missed
> >> something ? Please suggest.
> >>
> >>
>
> 
> > I understand you want to merge the changes you have done in
> the branch to the trunk. If that's the case then from the
> branch you use the --reintegrate option.
> >
> > The merge command you issued merges the changes between 475
> and 476 done to trunk into the directory you are in. Since
> the changes happened on the branch it's correct that it
> doesn't merge anything.
> >
> >
>
>
> Hello,
>
> Thanks a lot for your response. I am afraid but I am not
> fully understand the logic. Which I am following is collected
> from net and I have just doing the same. I admit I don't know
> the in-depth about how merging works. It might be interesting
> that I am now getting something new than the empty return as
> before. Please fine below

Ok, let's start on what you did before.

You created a branch "mybranch" from trunk to work on something. This is 
correct and the following is roughly what you should do in such cases

- create the branch (done)
- checkout the branch (done in branches/mybranch)
- work on the branch committing as many times as you like
- regularly merge the changes done in trunk
 cd branches/mybranch
 svn merge ^/trunk
 svn commit
- when you're done with the branch and you want to merge it back to trunk
 cd branches/mybranch
 svn merge ^/trunk
 svn commit
 cd trunk
 svn merge --reintegrate ^/branches/mybranch

This works because of merge-tracking. Unfortunately I think your version of SVN 
server (1.5.1) has some problem with merge-tracking. Other members of this ML 
hopefully will tell you for sure. I suggest you upgrade your server anyway to 
the latest SVN which is 1.6.9.

> ``
> svn diff -r 488:489
> Index: branches/bug/typo3conf/localconf.php
> ===
> --- branches/bug/typo3conf/localconf.php (revision 488)
> +++ branches/bug/typo3conf/localconf.php (revision 489)
> @@ -1,9 +1,12 @@
> 
> -qqwq
> -wq
> -wqq
> -qw
> +wew
> +wew
> +ew
> +wew
> +
> ``
>
> The modification is done at
> branches/bug/typo3conf/localconf.php. Now I try to merge it to trunk
>
> ```
> svn merge --dry-run -r 488:489 branches/bug/ trunk/
>
> --- Merging r489 into 'trunk':
> C trunk/typo3conf/localconf.php
> Summary of conflicts:
> Text conflicts: 1
> 

That usually means that there are some changes done in 
trunk/typo3conf/localconf.php that were not merged into 
branches/bug/type3conf/localconf.php.

What does the log command on both files show?

Giulio

Re: strange problem with subversion merge

[J. Bakshi]

On 03/02/2010 05:45 PM, Giulio Troccoli wrote:
>
>   
>> 
>
> Linedata Services (UK) Ltd
> Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
> Registered in England and Wales No 3027851VAT Reg No 778499447
>
> -Original Message-
>
>
>   
>> From: J. Bakshi [mailto:joyd...@infoservices.in]
>> Sent: 02 March 2010 11:56
>> To: Giulio Troccoli
>> Cc: users@subversion.apache.org
>> Subject: Re: strange problem with subversion merge
>>
>> On 03/02/2010 05:02 PM, Giulio Troccoli wrote:
>>
>> 
>> 
 
 svn merge -r 475:476 trunk/
 `
 just returns null value. It should merge the changes I made at
 branches/mybranch/folder1/file1 to trunk/folder1/file1.
 
>> Have I missed
>> 
 something ? Please suggest.


 
>> 
>> 
>>> I understand you want to merge the changes you have done in
>>>   
>> the branch to the trunk. If that's the case then from the
>> branch you use the --reintegrate option.
>> 
>>> The merge command you issued merges the changes between 475
>>>   
>> and 476 done to trunk into the directory you are in. Since
>> the changes happened on the branch it's correct that it
>> doesn't merge anything.
>> 
>>>
>>>   
>>
>> Hello,
>>
>> Thanks a lot for your response. I am afraid but I am not
>> fully understand the logic. Which I am following is collected
>> from net and I have just doing the same. I admit I don't know
>> the in-depth about how merging works. It might be interesting
>> that I am now getting something new than the empty return as
>> before. Please fine below
>> 
> Ok, let's start on what you did before.
>
> You created a branch "mybranch" from trunk to work on something. This is 
> correct and the following is roughly what you should do in such cases
>
> - create the branch (done)
> - checkout the branch (done in branches/mybranch)
> - work on the branch committing as many times as you like
> - regularly merge the changes done in trunk
>  cd branches/mybranch
>  svn merge ^/trunk
>  svn commit
> - when you're done with the branch and you want to merge it back to trunk
>  cd branches/mybranch
>  svn merge ^/trunk
>  svn commit
>  cd trunk
>  svn merge --reintegrate ^/branches/mybranch
>
> This works because of merge-tracking. Unfortunately I think your version of 
> SVN server (1.5.1) has some problem with merge-tracking. Other members of 
> this ML hopefully will tell you for sure. I suggest you upgrade your server 
> anyway to the latest SVN which is 1.6.9.
>
>   
>> ``
>> svn diff -r 488:489
>> Index: branches/bug/typo3conf/localconf.php
>> ===
>> --- branches/bug/typo3conf/localconf.php (revision 488)
>> +++ branches/bug/typo3conf/localconf.php (revision 489)
>> @@ -1,9 +1,12 @@
>> >
>> -qqwq
>> -wq
>> -wqq
>> -qw
>> +wew
>> +wew
>> +ew
>> +wew
>> +
>> ``
>>
>> The modification is done at
>> branches/bug/typo3conf/localconf.php. Now I try to merge it to trunk
>>
>> ```
>> svn merge --dry-run -r 488:489 branches/bug/ trunk/
>>
>> --- Merging r489 into 'trunk':
>> C trunk/typo3conf/localconf.php
>> Summary of conflicts:
>> Text conflicts: 1
>> 
>> 
> That usually means that there are some changes done in 
> trunk/typo3conf/localconf.php that were not merged into 
> branches/bug/type3conf/localconf.php.
>
> What does the log command on both files show?
>
> Giulioam now using 
>
>   


The point on svn version seems to valid. I can't upgrade the svn on the
server right now. but I am now using a machine which has a same svn
version i.e. 1.5 and here I found


svn merge --dry-run -r 490:491 trunk/typo3conf/ branches/bug/
Skipped missing target: 'branches/bug/localconf.php'
```

Just notice now svn reports totally a different points to be failure.

Though "svn diff -r 490:491" shows the differences.



-- 
জয়দীপ বক্সী

Why do you need to grant root access to subversion repository??

[Keith Theman]

Hello,

We had been using svn 1.3. We had multiple projects in a single repository, and 
we had apache with mod_dav as a front end. We configured the access control 
list disallow root access:

[myRepo:/]
#* = r

 but then allowed appropriate user access to their project folders:

[myRepo:/myProject]
jdoe = rw


Everything worked great, but then we updated to 1.6 and now we get permission 
errors unless we grant EVERYONE read access to the root of the repository! 
Everyone can see anything in the repository not good.  What is going on?

Ed
  
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

RE: Why do you need to grant root access to subversion repository??

[Bert Huijben]

Hi,

 

See issue #3242 (http://subversion.tigris.org/issues/show_bug.cgi?id=3242)

 

An incomplete fix should be available (if it gets enough votes) in 1.6.10;
see http://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS.

 

Bert Huijben

 

From: Keith Theman [mailto:xray...@hotmail.com] 
Sent: dinsdag 2 maart 2010 14:25
To: users@subversion.apache.org
Subject: Why do you need to grant root access to subversion repository??

 

Hello,

We had been using svn 1.3. We had multiple projects in a single repository,
and we had apache with mod_dav as a front end. We configured the access
control list disallow root access:

[myRepo:/]
#* = r

 but then allowed appropriate user access to their project folders:

[myRepo:/myProject]
jdoe = rw


Everything worked great, but then we updated to 1.6 and now we get
permission errors unless we grant EVERYONE read access to the root of the
repository! Everyone can see anything in the repository not good.  What
is going on?

Ed

  _  

Hotmail: Trusted email with powerful SPAM protection. Sign up now.
 

RE: Why do you need to grant root access to subversion repository??

[Keith Theman]

Thank You Bert,

but what do you mean "an incomplete fix" ? and how can I vote for this? I can't 
believe this bug exists! Is there a work around while we wait for the fix?

Ed

From: b...@qqmail.nl
To: xray...@hotmail.com; users@subversion.apache.org
Subject: RE: Why do you need to grant root access to subversion repository??
Date: Tue, 2 Mar 2010 14:29:16 +0100



Hi, See issue #3242 
(http://subversion.tigris.org/issues/show_bug.cgi?id=3242) An incomplete fix 
should be available (if it gets enough votes) in 1.6.10; see 
http://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS.   
  Bert Huijben From: Keith Theman [mailto:xray...@hotmail.com] 
Sent: dinsdag 2 maart 2010 14:25
To: users@subversion.apache.org
Subject: Why do you need to grant root access to subversion repository?? Hello,

We had been using svn 1.3. We had multiple projects in a single repository, and 
we had apache with mod_dav as a front end. We configured the access control 
list disallow root access:

[myRepo:/]
#* = r

 but then allowed appropriate user access to their project folders:

[myRepo:/myProject]
jdoe = rw


Everything worked great, but then we updated to 1.6 and now we get permission 
errors unless we grant EVERYONE read access to the root of the repository! 
Everyone can see anything in the repository not good.  What is going on?

EdHotmail: Trusted email with powerful SPAM protection. Sign up now.
  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/

Re: Why do you need to grant root access to subversion repository??

[C. Michael Pilato]

There were two different things that changed in Subversion 1.5 that led to this.

1.  Subversion started firing of OPTIONS requests for all operations, often
against the repository root URL.

2.  'svn copy' and 'svn move' started allowing folks to copy/move multiple
items at once, and the code was a little lazy about determining the right
URL on which to base those multi-target operations.

The "incomplete fix" Bert mentions is that (1) above has been remedied on
trunk and proposed for backport to 1.6.x, but (2) has only been remedied on
trunk.  The backport was just too hairy, and the number of folks affected by
the bug too small, to bother with.

Voting is limited to committers in this case (a backport means not just "I
think we should fix this bug" but also "I've reviewed the code myself, it
looks sane, doesn't appear to cause more problems, etc.".

As for a workaround besides the obvious one (granting read access at the
root), perhaps you could build the HEAD of Subversion's 1.6.x branch for
yourself.  If that's not an option, then short of rolling back to the latest
1.4.x release (the last releases before the bugs were introduced), you'll
just need to wait for 1.6.10 to be released (assuming that more folks vote
the backport into that branch).


Keith Theman wrote:
> Thank You Bert,
> 
> but what do you mean "an incomplete fix" ? and how can I vote for this?
> I can't believe this bug exists! Is there a work around while we wait
> for the fix?
> 
> Ed
> 
> 
> From: b...@qqmail.nl
> To: xray...@hotmail.com; users@subversion.apache.org
> Subject: RE: Why do you need to grant root access to subversion repository??
> Date: Tue, 2 Mar 2010 14:29:16 +0100
> 
> Hi,
> 
>  
> 
> See issue #3242 (http://subversion.tigris.org/issues/show_bug.cgi?id=3242)
> 
>  
> 
> An incomplete fix should be available (if it gets enough votes) in
> 1.6.10; see
> http://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS.
> 
>  
> 
> Bert Huijben
> 
>  
> 
> *From:* Keith Theman [mailto:xray...@hotmail.com]
> *Sent:* dinsdag 2 maart 2010 14:25
> *To:* users@subversion.apache.org
> *Subject:* Why do you need to grant root access to subversion repository??
> 
>  
> 
> Hello,
> 
> We had been using svn 1.3. We had multiple projects in a single
> repository, and we had apache with mod_dav as a front end. We configured
> the access control list disallow root access:
> 
> [myRepo:/]
> #* = r
> 
>  but then allowed appropriate user access to their project folders:
> 
> [myRepo:/myProject]
> jdoe = rw
> 
> 
> Everything worked great, but then we updated to 1.6 and now we get
> permission errors unless we grant EVERYONE read access to the root of
> the repository! Everyone can see anything in the repository not
> good.  What is going on?
> 
> Ed
> 
> 
> 
> Hotmail: Trusted email with powerful SPAM protection. Sign up now.
> 
> 
> 
> 
> Hotmail: Powerful Free email with security by Microsoft. Get it now.
> 


-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: List of all files in conflict

[C. Michael Pilato]

Lasse Kliemann wrote:
> Is there a reliable and direct way to get a list of all files 
> that are in conflict for a particular working copy? Of course, 
> one can parse the output of 'svn status' or 'svn status --xml', 
> but maybe there is something like 'svn status --conflicts'?

There's a thinly veiled sense of distrust in Subversion's command-line
output here whose source I'm sure would make a great anecdote, but let me
assure you that the likes of 'svn status' piped through an appropriate
'grep' will do exactly what you want.

Alternatively, you can write you own program around Subversion's public API
to harvest and report only the conflicted files.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Broken Revision in FSFS Repo

[Mariusz Droździel]

Hello,

After some time it turned out, that there are few revisions in our
repository, which are broken, probably on the filesystem level.
Unfortunetely as time went by, backups we made contain only those
broken revisions so we have no chance in getting stuph working just by
simple recovery. Only hope is to fix the repository in some way. At
this point in time it is impossible to do a full checkout.

% svnadmin verify /storage/svn
[...]
* Verified revision 1025.
* Verified revision 1026.
svnadmin: Decompression of svndiff data failed

This is the most common error, which we get while trying to checkout the stuph.

fsfsverify.py tool points out, that revision 1027 is broken in several
places. Unfortunetely after few fixes the tool crashes on the 1027
rev.

% fsfsverify.py /storage/svn/db/revs/1/1027

NodeRev Id: 2z-1027.0-68.r1027/2303848
 type: file
 text: DELTA 1027 2088431 1684 5317 447a4956b16f81132e54669d33c188f2
 cpath: /_Projekty/Rekl/dd.aspx.resx
 copyroot: 68 /_Projekty
Traceback (most recent call last):
  File "/usr/local/bin/fsfsverify.py", line 1134, in 
options.dumpWindows)
  File "/usr/local/bin/fsfsverify.py", line 571, in verify
svndiff = Svndiff(f, self.length)
  File "/usr/local/bin/fsfsverify.py", line 461, in __init__
(self.startingOffset)
__main__.InvalidSvndiffHeader: Invalid svndiff header at offset 2088437

We tried hard to get this thing working, but in the end I have no idea
why it is failing and how to fix it.

Next thing we tried to do, is to create dumps without broken
revisions. During the process it turned out, that out of over 8500
revs 5 is broken. Using svnadmin dump --incremental we managed to take
all the working revs out, but we have no idea how to put them
together.

Creating new repo from scratch and importing dumps doesn't work.
Leading dump is loaded without any problem (0:1026), but the 2nd dump
(1028:6675) fails at 2761 with following Error:

<<< Started new transaction, based on original revision 2763
svnadmin: File not found: revision 2761, path '/_Projekty/Rekl
 * adding path : _Projekty/www/Rekl ...#

No revision over 2761 is inserted.

After a bit more gooling we found out a tool called svndumptool
(0.6.1). Merge was looking very promissing at the start, but it turned
out it fails now and then on certain revisions. Revisions it fails on
are seem to be fine in the original repo, but for some reason it just
wont work. At the start we tried to skip the revisions which aren't
seem to be loaded correctly. After some time it turned out, that
around rev 7000 every 1  in 5 revisions was broken. It makes no sence
to make a recovery, while we have to skip 20% or more of the data.

Revision: 7192 from r7192 all-dump-1:7202.txt
Revision: 7193 from r7193 all-dump-1:7202.txt
Revision: 7194 from r7194 all-dump-1:7202.txt
Revision: 7195 from r7204 7204:7269.txt
Revision: 7196 from r7205 7204:7269.txt
Revision: 7197 from r7206 7204:7269.txt
Revision: 7198 from r7207 7204:7269.txt
Revision: 7199 from r7208 7204:7269.txt
Revision: 7200 from r7209 7204:7269.txt
Revision: 7201 from r7210 7204:7269.txt
Traceback (most recent call last):
  File "/tmp/svndumptool-0.6.1/svndumptool.py", line 119, in 
sys.exit( func( appname, args ) )
  File "/tmp/svndumptool-0.6.1/svndump/merge.py", line 564, in
svndump_merge_cmdline
merge.merge()
  File "/tmp/svndumptool-0.6.1/svndump/merge.py", line 257, in merge
self.__copy_revision( oldestIndex )
  File "/tmp/svndumptool-0.6.1/svndump/merge.py", line 291, in __copy_revision
newNode = self.__change_node( dumpIndex, node )
  File "/tmp/svndumptool-0.6.1/svndump/merge.py", line 330, in __change_node
newFromRev = self.__in_rev_nr_maps[dumpIndex][fromRev]
KeyError: 7188

I have no idea why it has to do something wih rev 7188, which was
imported earlier. If I now skip rev 7203 it will move on, but it will
fail again somewhere around 7210.

Does any one have any tips on how to recover this repository?

Thanks in advance!

-- 
Mariusz Drozdziel

RE: Why do you need to grant root access to subversion repository??

[Keith Theman]

Thank you for the clarification. Very helpful.

Not being a member of the subversion voting elite, what is the probability 
(polling?) that this bug will be fixed in 1.6.10?

If this bug is not fixed, then I will have no other recourse but to move to 
mecurial. Bummer I really like svn.

Ed 

> Date: Tue, 2 Mar 2010 08:49:40 -0500
> From: cmpil...@collab.net
> To: xray...@hotmail.com
> CC: b...@qqmail.nl; users@subversion.apache.org
> Subject: Re: Why do you need to grant root access to subversion repository??
> 
> There were two different things that changed in Subversion 1.5 that led to 
> this.
> 
> 1.  Subversion started firing of OPTIONS requests for all operations, often
> against the repository root URL.
> 
> 2.  'svn copy' and 'svn move' started allowing folks to copy/move multiple
> items at once, and the code was a little lazy about determining the right
> URL on which to base those multi-target operations.
> 
> The "incomplete fix" Bert mentions is that (1) above has been remedied on
> trunk and proposed for backport to 1.6.x, but (2) has only been remedied on
> trunk.  The backport was just too hairy, and the number of folks affected by
> the bug too small, to bother with.
> 
> Voting is limited to committers in this case (a backport means not just "I
> think we should fix this bug" but also "I've reviewed the code myself, it
> looks sane, doesn't appear to cause more problems, etc.".
> 
> As for a workaround besides the obvious one (granting read access at the
> root), perhaps you could build the HEAD of Subversion's 1.6.x branch for
> yourself.  If that's not an option, then short of rolling back to the latest
> 1.4.x release (the last releases before the bugs were introduced), you'll
> just need to wait for 1.6.10 to be released (assuming that more folks vote
> the backport into that branch).
> 
> 
> Keith Theman wrote:
> > Thank You Bert,
> > 
> > but what do you mean "an incomplete fix" ? and how can I vote for this?
> > I can't believe this bug exists! Is there a work around while we wait
> > for the fix?
> > 
> > Ed
> > 
> > 
> > From: b...@qqmail.nl
> > To: xray...@hotmail.com; users@subversion.apache.org
> > Subject: RE: Why do you need to grant root access to subversion repository??
> > Date: Tue, 2 Mar 2010 14:29:16 +0100
> > 
> > Hi,
> > 
> >  
> > 
> > See issue #3242 (http://subversion.tigris.org/issues/show_bug.cgi?id=3242)
> > 
> >  
> > 
> > An incomplete fix should be available (if it gets enough votes) in
> > 1.6.10; see
> > http://svn.apache.org/repos/asf/subversion/branches/1.6.x/STATUS.
> > 
> >  
> > 
> > Bert Huijben
> > 
> >  
> > 
> > *From:* Keith Theman [mailto:xray...@hotmail.com]
> > *Sent:* dinsdag 2 maart 2010 14:25
> > *To:* users@subversion.apache.org
> > *Subject:* Why do you need to grant root access to subversion repository??
> > 
> >  
> > 
> > Hello,
> > 
> > We had been using svn 1.3. We had multiple projects in a single
> > repository, and we had apache with mod_dav as a front end. We configured
> > the access control list disallow root access:
> > 
> > [myRepo:/]
> > #* = r
> > 
> >  but then allowed appropriate user access to their project folders:
> > 
> > [myRepo:/myProject]
> > jdoe = rw
> > 
> > 
> > Everything worked great, but then we updated to 1.6 and now we get
> > permission errors unless we grant EVERYONE read access to the root of
> > the repository! Everyone can see anything in the repository not
> > good.  What is going on?
> > 
> > Ed
> > 
> > 
> > 
> > Hotmail: Trusted email with powerful SPAM protection. Sign up now.
> > 
> > 
> > 
> > 
> > Hotmail: Powerful Free email with security by Microsoft. Get it now.
> > 
> 
> 
> -- 
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
> 
  
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

RE: strange problem with subversion merge

[Giulio Troccoli]

>  
>  svn merge -r 475:476 trunk/
>  `

> 
> svn merge --dry-run -r 490:491 trunk/typo3conf/ branches/bug/
> Skipped missing target: 'branches/bug/localconf.php'
> ```

But these commands are not the same.

>From your previous email I understand the bug branch was created as a copy of 
>trunk. What you're trying here is to merge the changes in trunk/typo3conf to a 
>copy of trunk, instead of a copy of trunk/typo3conf.

You seem to be very confused about merging. Maybe you should (re)read the 
documenation. http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

Re: Why do you need to grant root access to subversion repository??

[Stefan Sperling]

On Tue, Mar 02, 2010 at 09:11:13AM -0500, Keith Theman wrote:
> 
> Thank you for the clarification. Very helpful.
> 
> Not being a member of the subversion voting elite, what is the
> probability (polling?) that this bug will be fixed in 1.6.10?

Very likely.
The height of the backport voting season happens when Hyrum
announces that he's thinking about making a new release.
Issue #3242 is important enough that I'd expect many developers
to strongly consider reviewing it once 1.6.10 is near (myself included).
The fix already has two votes and needs just one more vote to make
the release.

> If this bug is not fixed, then I will have no other recourse but to
> move to mecurial. Bummer I really like svn.

Mercurial is nice, too. But afaik it does not have path-based authz,
so I wonder why you'd consider Mercurial if you need authz so much
that you care about issue #3242?

Stefan

Re: Why do you need to grant root access to subversion repository??

[Stefan Sperling]

On Tue, Mar 02, 2010 at 08:49:40AM -0500, C. Michael Pilato wrote:
> As for a workaround besides the obvious one (granting read access at the
> root), perhaps you could build the HEAD of Subversion's 1.6.x branch for
> yourself.

Until the fix is merged into the 1.6.x branch, you probably mean the HEAD
of ^/subversion/branches/1.6.x-issue-3242-partial ?

Stefan

Re: Why do you need to grant root access to subversion repository??

[C. Michael Pilato]

Stefan Sperling wrote:
> On Tue, Mar 02, 2010 at 08:49:40AM -0500, C. Michael Pilato wrote:
>> As for a workaround besides the obvious one (granting read access at the
>> root), perhaps you could build the HEAD of Subversion's 1.6.x branch for
>> yourself.
> 
> Until the fix is merged into the 1.6.x branch, you probably mean the HEAD
> of ^/subversion/branches/1.6.x-issue-3242-partial ?

Doh -- yes, that's what I meant.  Thanks for the correction, Stefan.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: Why do you need to grant root access to subversion repository??

[Ulrich Eckhardt]

On Tuesday 02 March 2010, Keith Theman wrote:
> Thank you for the clarification. Very helpful.
>
> Not being a member of the subversion voting elite, what is the probability
> (polling?) that this bug will be fixed in 1.6.10?
>
> If this bug is not fixed, then I will have no other recourse but to move to
> mecurial. Bummer I really like svn.

You have been given the option to try the branch where the bug is fixed. Other 
options are to live (maybe temporarily) with the fact that users can see 
other users' directories.

A third option would be to actually use separate repositories for separate 
users and only grant the "owner" any access at all. If the repositories 
contain private stuff, you could then even remove a whole user, which is not 
that easy in a shared repository.

Lastly, shame on you for trying to blackmail volunteers with "fix this or I'll 
use Mercurial". If you paid for Subversion (Which is yet another option btw!) 
you could demand things, but otherwise that's just low and the devs don't 
deserve it.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: Tigris binary packages for Windows

[kmradke]

"Troy Simpson"  wrote on 03/01/2010 08:44:54 PM:
> I can still build the installer, but I have never built binaries.  
> The installer code in the repository is NOT the latest code.  I had 
> lost commit access for a time during the transition and by the time 
> I got that access back there are no more binaries, so it has been 
> pointless to continue development.  If someone could produce 
> binaries I could get the installer back on track, otherwise it?s not
> worth spending any time on if the project will not support (as in 
> supply) windows binaries.
> 
> I was advised to discuss this on the dev list, which is what I did, 
> however there has been zero response.  There is more discussion on 
> the user end than the developer end.  If anyone in user-land has the
> capability to construct the binaries in a similar fashion to the way
> they were produced before, I for one would bring this to the 
> attention of the developer list if nobody else does.  It is my 
> opinion that the project should have a ?supported? release to assist
> with bug finding and to provide end-users with a standard base-level 
release.

I too posted a question about the windows build process, but without
the recipe, I just haven't found the time to dig into it myself.
(I created my virtual machine, but wasn't even sure what build tool
 versions were preferred.)

I believe there are windows binaries generated by the windows build bots.
Not sure if the build bots run on the release branches for all platforms,
but that could probably be remedied.  No idea if those binaries
are built in a compatible way to the previous release ones...

There was some discussion if some of the Apache infrastructure could
be used for the build.  Not sure if that was resolved or pursued.

If I remember correctly, DJ's build machine completely died and is the
main reason he was unable to perform the build.

Kevin R.

Programming a Watcher File

[David Weintraub]

One of the tech leads wants to be able to program a watch file, so
that when a certain set of developers change a particular file,
certain other developers get notified. Thus, we need to be able to
program what files, what developers do the commit, and what developers
receive the notification. I'd like to do this, so this developer can
maintain this file himself instead of me having to maintain it which
means it can't be a text file on the Subversion server.

I'm working with something like this now. I have a configuration file
where you setup the various parameters (specifying files via globbing
or regex), who does the commit, and who receives the email. The
configuration file sits in the source repository, so this tech lead
has access to it.

I was wondering if anyone already has a post-commit hook script like
this already setup. I know there's one included in Subversion, but
this one uses a text file that's accessible to the hook script and its
setup isn't that flexible.

If not, I'll finish up the one I'm working on.

-- 
David Weintraub
qazw...@gmail.com

RE: Why do you need to grant root access to subversion repository??

[Keith Theman]

Blackmail is when a person threatens to reveal a secret of another person 
unless they do something.

There is no secret here. We are just an enterprise that needs to have some 
modicum of access control. Which sounds like will be restored shortly. But as I 
read your dev's discourse, this bug has rightfully introduce questions in the 
user community about how this bug could be allowed, and why it has lingered for 
so long!

We love svn, it has been used in our organization for 2 years, and has 
performed flawlessly. Keep up the great work!

Ed

> 
> Lastly, shame on you for trying to blackmail volunteers with "fix this or 
> I'll 
> use Mercurial". If you paid for Subversion (Which is yet another option btw!) 
> you could demand things, but otherwise that's just low and the devs don't 
> deserve it.
> 
> Uli
> 
> -- 
> ML: http://subversion.tigris.org/mailing-list-guidelines.html
> FAQ: http://subversion.tigris.org/faq.html
> Docs: http://svnbook.red-bean.com/
> 
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> 
> **
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **
>Visit our website at 
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
> sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
> weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
> verantwortlich.
> **
> 
  
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/

RE: Why do you need to grant root access to subversion repository??

[Bob Archer]

If you are thinking of going with mercurial you could do that same with svn... 
have a separate repo for each project and only add users to the repos they 
should have access to.

BOb


From: Keith Theman [mailto:xray...@hotmail.com]
Sent: Tuesday, March 02, 2010 11:41 AM
To: users@subversion.apache.org
Subject: RE: Why do you need to grant root access to subversion repository??

Blackmail is when a person threatens to reveal a secret of another person 
unless they do something.

There is no secret here. We are just an enterprise that needs to have some 
modicum of access control. Which sounds like will be restored shortly. But as I 
read your dev's discourse, this bug has rightfully introduce questions in the 
user community about how this bug could be allowed, and why it has lingered for 
so long!

We love svn, it has been used in our organization for 2 years, and has 
performed flawlessly. Keep up the great work!

Ed

>
> Lastly, shame on you for trying to blackmail volunteers with "fix this or I'll
> use Mercurial". If you paid for Subversion (Which is yet another option btw!)
> you could demand things, but otherwise that's just low and the devs don't
> deserve it.
>
> Uli
>
> --
> ML: http://subversion.tigris.org/mailing-list-guidelines.html
> FAQ: http://subversion.tigris.org/faq.html
> Docs: http://svnbook.red-bean.com/
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> **
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **
> Visit our website at 
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
> sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
> weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
> verantwortlich.
> **
>

Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up 
now.

Re: Why do you need to grant root access to subversion repository??

[Stefan Sperling]

On Tue, Mar 02, 2010 at 11:41:00AM -0500, Keith Theman wrote:
> But as I read your dev's discourse, this bug has rightfully
> introduce questions in the user community about how this bug could be
> allowed, and why it has lingered for so long!

Not only in the user community:
http://2009.subconf.de/fileadmin/PDF_Dateien/CMConf___SubConf/PDF_Vortraege/S._Sperling_und_H._K._Wright.pdf

Stefan

svn usage tips

[Paul Decker]

Hi list, 



I recently changed jobs and went from a cvs house to a svn house.   They have 
many projects and have an extensive shared source base.   I would like to know 
if there is a way to setup to check out a list of folders or files.   In other 
words, for each project, I want to check out only files that are directly 
related to that project rather than evey file which is in the shared directory. 



ie. 



projects\ 

\display 

\display2 

\display3 

\comm 

\usb 

\tcp 

\keyboard 

\spi 

\i2c 

\flash 

\eeprom 



Some projects use {display, comm, keyboard, spi } while other projects use 
{display, usb, spi, flash }   currently, the only way of working is to check 
out all folders. 



Is there a better way to work? 



thanks, 

Paul 

Re: svn usage tips

[Mark Keisler]

On Tue, Mar 2, 2010 at 12:07 PM, Paul Decker  wrote:

> Hi list,
>
>
>
> I recently changed jobs and went from a cvs house to a svn house.   They
> have many projects and have an extensive shared source base.   I would like
> to know if there is a way to setup to check out a list of folders or
> files.   In other words, for each project, I want to check out only files
> that are directly related to that project rather than evey file which is in
> the shared directory.
>
>
>
> ie.
>
>
>
> projects\
>
> \display
>
> \display2
>
> \display3
>
> \comm
>
> \usb
>
> \tcp
>
> \keyboard
>
> \spi
>
> \i2c
>
> \flash
>
> \eeprom
>
>
>
> Some projects use {display, comm, keyboard, spi } while other projects use
> {display, usb, spi, flash }   currently, the only way of working is to check
> out all folders.
>
>
>
> Is there a better way to work?
>
>
>
> thanks,
>
> Paul
>
>
>
See  http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

Subversion repository utilization statistics?

[Keith Theman]

Hello,

We have multiple projects in a single repo. Does anyone have any handy scripts 
that can provide utilization statistics for the repo? 

Ed
  
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/

Re: Tigris binary packages for Windows

[David Darj]

On 2010-03-02 07:57, Olivier Sannier wrote:

Troy Simpson wrote:


Hi,

I can still build the installer, but I have never built binaries.  
The installer code in the repository is NOT the latest code.  I had 
lost commit access for a time during the transition and by the time I 
got that access back there are no more binaries, so it has been 
pointless to continue development.  If someone could produce binaries 
I could get the installer back on track, otherwise it’s not worth 
spending any time on if the project will not support (as in supply) 
windows binaries.


I was advised to discuss this on the dev list, which is what I did, 
however there has been zero response.  There is more discussion on 
the user end than the developer end.  If anyone in user-land has the 
capability to construct the binaries in a similar fashion to the way 
they were produced before, I for one would bring this to the 
attention of the developer list if nobody else does.  It is my 
opinion that the project should have a ‘supported’ release to assist 
with bug finding and to provide end-users with a standard base-level 
release.



So the situation is as follows:

The previous builder (DJ Heap?) does not have the time to build the 
Win32 binaries anymore.
I, for one, could dedicate a few hours to create the latest ones and 
the next ones as well. It does not seem too much complicated to build 
them.

What I'm lacking is a description of what to run and in what order.
I mean, there are Python scripts related to win32 in the build folder, 
but I am not sure what they are doing. Having a simple "step by step" 
guide would actually save time.

Is there a way to ask the previous builder to at least document this?

Regards
Olivier


There is instructions how to build Win32 binaries in the INSTALL file.
However, I tried twice (once at work and once at home) and failed with 
compilation errors. Maybe because of using wrong version of dependencies 
or wrong parameters to the build scripts.

And I havn't had the time to track those errors down to their source.

I have a virtual machine I can use for the build process.
I too would be very happy if DJ could come up with a detailed 
description of his build process.

Then I would gladly take over and build upcoming versions for the community.

/David

Re: Tigris binary packages for Windows

[sNop]

Hi Dave,

Dne 2. 3. 2010 19:42, David Darj napsal(a):
> Then I would gladly take over and build upcoming versions for the
> community.
>
> /David
>

That would by cool.


signature.asc
Description: OpenPGP digital signature

Re: Tigris binary packages for Windows

[Daniel Shahaf]

If you try to build and fail, feel free to post to this list and we'll help.

There are a couple of other ways to build svn besides what's documented in 
INSTALL :-).  I posted to this list a makefile that I use (with VC 
express) for my windows build, and IIRC the tortoisesvn folks (and other 
windows clients) have their own build scripts too.

(Oh, and I don't know if anyone ever tried to cross-compile svn windows 
binaries on other OSes.)

Good luck!

Daniel

David Darj wrote on Tue, 2 Mar 2010 at 19:42 +0100:
> There is instructions how to build Win32 binaries in the INSTALL file.
> However, I tried twice (once at work and once at home) and failed with
> compilation errors. Maybe because of using wrong version of dependencies or
> wrong parameters to the build scripts.
> And I havn't had the time to track those errors down to their source.
> 
> I have a virtual machine I can use for the build process.
> I too would be very happy if DJ could come up with a detailed description of
> his build process.
> Then I would gladly take over and build upcoming versions for the community.
> 
> /David
> 
> 

Re: svn usage tips

[David Weintraub]

Let me get this straight, you're not talking about checking out a
single project vs. the whole tree. You're talking about checking out a
project, but not the externals directories?

You can take a look at several things:

* There's an --ignore-externals flag when you do a checkout. This
prevents any externals directory from being checked out.

* Take a look at the --depth switch. You can checkout a directory,
without checking out the sub-directories, then just update the
subdirectories you want. (Note: There's a --set-depth flag on the
update command to override the setting on the checkout command.

(See http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkouts
for more information on the depth switch.)

On Tue, Mar 2, 2010 at 1:07 PM, Paul Decker  wrote:
> Hi list,
>
>
>
> I recently changed jobs and went from a cvs house to a svn house.   They
> have many projects and have an extensive shared source base.   I would like
> to know if there is a way to setup to check out a list of folders or
> files.   In other words, for each project, I want to check out only files
> that are directly related to that project rather than evey file which is in
> the shared directory.
>
>
>
> ie.
>
>
>
> projects\
>
> \display
>
> \display2
>
> \display3
>
> \comm
>
> \usb
>
> \tcp
>
> \keyboard
>
> \spi
>
> \i2c
>
> \flash
>
> \eeprom
>
>
>
> Some projects use {display, comm, keyboard, spi } while other projects use
> {display, usb, spi, flash }   currently, the only way of working is to check
> out all folders.
>
>
>
> Is there a better way to work?
>
>
>
> thanks,
>
> Paul
>
>



-- 
David Weintraub
qazw...@gmail.com

Re: svn usage tips

[Paul Decker]

I am talking about checking out a single project, however the "projects" all 
use the same folders, like shared folders.  So when you do a get on the top 
level, you get all the files for every project rather than just the files for 
the project of interest 



- Original Message - 
From: "David Weintraub"  
To: "Paul Decker"  
Cc: users@subversion.apache.org 
Sent: Tuesday, March 2, 2010 2:08:55 PM GMT -05:00 US/Canada Eastern 
Subject: Re: svn usage tips 

Let me get this straight, you're not talking about checking out a single 
project vs. the whole tree. You're talking about checking out a project, but 
not the externals directories? You can take a look at several things: * There's 
an --ignore-externals flag when you do a checkout. This prevents any externals 
directory from being checked out. * Take a look at the --depth switch. You can 
checkout a directory, without checking out the sub-directories, then just 
update the subdirectories you want. (Note: There's a --set-depth flag on the 
update command to override the setting on the checkout command. (See 
http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkouts for 
more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM, Paul 
Decker wrote: > Hi list, > > > > I recently changed jobs and went from a cvs 
house to a svn house.   They > have many projects and have an extensive shared 
source base.   I would like > to know if there is a way to setup to check out a 
list of folders or > files.   In other words, for each project, I want to check 
out only files > that are directly related to that project rather than evey 
file which is in > the shared directory. > > > > ie. > > > > projects\ > > 
\display > > \display2 > > \display3 > > \comm > > \usb > > \tcp > > \keyboard 
> > \spi > > \i2c > > \flash > > \eeprom > > > > Some projects use {display, 
comm, keyboard, spi } while other projects use > {display, usb, spi, flash }   
currently, the only way of working is to check > out all folders. > > > > Is 
there a better way to work? > > > > thanks, > > Paul > > -- David Weintraub 
qazw...@gmail.com 
Let me get this straight, you're not talking about checking out a single 
project vs. the whole tree. You're talking about checking out a project, but 
not the externals directories? You can take a look at several things: * There's 
an --ignore-externals flag when you do a checkout. This prevents any externals 
directory from being checked out. * Take a look at the --depth switch. You can 
checkout a directory, without checking out the sub-directories, then just 
update the subdirectories you want. (Note: There's a --set-depth flag on the 
update command to override the setting on the checkout command. (See 
http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkouts for 
more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM, Paul 
Decker wrote: > Hi list, > > > > I recently changed jobs and went from a cvs 
house to a svn house.   They > have many projects and have an extensive shared 
source base.   I would like > to know if there is a way to setup to check out a 
list of folders or > files.   In other words, for each project, I want to check 
out only files > that are directly related to that project rather than evey 
file which is in > the shared directory. > > > > ie. > > > > projects\ > > 
\display > > \display2 > > \display3 > > \comm > > \usb > > \tcp > > \keyboard 
> > \spi > > \i2c > > \flash > > \eeprom > > > > Some projects use {display, 
comm, keyboard, spi } while other projects use > {display, usb, spi, flash }   
currently, the only way of working is to check > out all folders. > > > > Is 
there a better way to work? > > > > thanks, > > Paul > > -- David Weintraub 
qazw...@gmail.com

AW: Broken Revision in FSFS Repo

[Kutter, Martin]

> Mariusz Droździel wrote:
> After some time it turned out, that there are few revisions in our
> repository, which are broken, probably on the filesystem level.
> 
> % svnadmin verify /storage/svn
> [...]
> * Verified revision 1025.
> * Verified revision 1026.
> svnadmin: Decompression of svndiff data failed

This sounds a bit like our issue discussed in thread 
"Corrupted FSFS commit" just a few days ago on this list.

We managed to create a copy of the repository without the corrupted 
files using path-based authorization and svnsync.

However, I'm a bit concerned about the issue arising again: Is there
some error in svn which allows for corrupted FSFS revisions to 
enter into the repository?

Regards,

Martin

Re: Subversion repository utilization statistics?

[Tyler Roscoe]

On Tue, Mar 02, 2010 at 01:24:16PM -0500, Keith Theman wrote:
> We have multiple projects in a single repo. Does anyone have any handy
> scripts that can provide utilization statistics for the repo? 

What, specifically, do you mean by "utilization statistics"?

tyler

RE: svn usage tips

[Bob Archer]

Why not set up your projects so they only include the needed shared folders 
using externals?

BOb


From: Paul Decker [mailto:kg...@comcast.net]
Sent: Tuesday, March 02, 2010 2:31 PM
To: David Weintraub
Cc: users@subversion.apache.org
Subject: Re: svn usage tips

I am talking about checking out a single project, however the "projects" all 
use the same folders, like shared folders.  So when you do a get on the top 
level, you get all the files for every project rather than just the files for 
the project of interest



- Original Message -
From: "David Weintraub" 
To: "Paul Decker" 
Cc: users@subversion.apache.org
Sent: Tuesday, March 2, 2010 2:08:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: svn usage tips

Let me get this straight, you're not talking about checking out a single 
project vs. the whole tree. You're talking about checking out a project, but 
not the externals directories? You can take a look at several things: * There's 
an --ignore-externals flag when you do a checkout. This prevents any externals 
directory from being checked out. * Take a look at the --depth switch. You can 
checkout a directory, without checking out the sub-directories, then just 
update the subdirectories you want. (Note: There's a --set-depth flag on the 
update command to override the setting on the checkout command. (See 
http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkouts for 
more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM, Paul 
Decker wrote: > Hi list, > > > > I recently changed jobs and went from a cvs 
house to a svn house.   They > have many projects and have an extensive shared 
source base.   I would like > to know if there is a way to setup to check out a 
list of folders or > files.   In other words, for each project, I want to check 
out only files > that are directly related to that project rather than evey 
file which is in > the shared directory. > > > > ie. > > > > projects\ > > 
\display > > \display2 > > \display3 > > \comm > > \usb > > \tcp > > \keyboard 
> > \spi > > \i2c > > \flash > > \eeprom > > > > Some projects use {display, 
comm, keyboard, spi } while other projects use > {display, usb, spi, flash }   
currently, the only way of working is to check > out all folders. > > > > Is 
there a better way to work? > > > > thanks, > > Paul > > -- David Weintraub 
qazw...@gmail.com
Let me get this straight, you're not talking about checking out a single 
project vs. the whole tree. You're talking about checking out a project, but 
not the externals directories? You can take a look at several things: * There's 
an --ignore-externals flag when you do a checkout. This prevents any externals 
directory from being checked out. * Take a look at the --depth switch. You can 
checkout a directory, without checking out the sub-directories, then just 
update the subdirectories you want. (Note: There's a --set-depth flag on the 
update command to override the setting on the checkout command. (See 
http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkouts for 
more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM, Paul 
Decker wrote: > Hi list, > > > > I recently changed jobs and went from a cvs 
house to a svn house.   They > have many projects and have an extensive shared 
source base.   I would like > to know if there is a way to setup to check out a 
list of folders or > files.   In other words, for each project, I want to check 
out only files > that are directly related to that project rather than evey 
file which is in > the shared directory. > > > > ie. > > > > projects\ > > 
\display > > \display2 > > \display3 > > \comm > > \usb > > \tcp > > \keyboard 
> > \spi > > \i2c > > \flash > > \eeprom > > > > Some projects use {display, 
comm, keyboard, spi } while other projects use > {display, usb, spi, flash }   
currently, the only way of working is to check > out all folders. > > > > Is 
there a better way to work? > > > > thanks, > > Paul > > -- David Weintraub 
qazw...@gmail.com

RE: Subversion repository utilization statistics?

[Keith Theman]

as in number of files in a project, mb's in project, number of transactions, etc

> Date: Tue, 2 Mar 2010 12:18:55 -0800
> From: ty...@cryptio.net
> To: xray...@hotmail.com
> CC: users@subversion.apache.org
> Subject: Re: Subversion repository utilization statistics?
> 
> On Tue, Mar 02, 2010 at 01:24:16PM -0500, Keith Theman wrote:
> > We have multiple projects in a single repo. Does anyone have any handy
> > scripts that can provide utilization statistics for the repo? 
> 
> What, specifically, do you mean by "utilization statistics"?
> 
> tyler
  
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/

Re: svn usage tips

[Mark Keisler]

So are all of these projects in the same repository?  That's what I was
assuming.

-- 
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."


On Tue, Mar 2, 2010 at 2:21 PM, Bob Archer  wrote:

>  Why not set up your projects so they only include the needed shared
> folders using externals?
>
>
>
> BOb
>
>
>
>
>
> *From:* Paul Decker [mailto:kg...@comcast.net]
> *Sent:* Tuesday, March 02, 2010 2:31 PM
> *To:* David Weintraub
>
> *Cc:* users@subversion.apache.org
> *Subject:* Re: svn usage tips
>
>
>
> I am talking about checking out a single project, however the "projects"
> all use the same folders, like shared folders.  So when you do a get on the
> top level, you get all the files for every project rather than just the
> files for the project of interest
>
>
>
> - Original Message -
> From: "David Weintraub" 
> To: "Paul Decker" 
> Cc: users@subversion.apache.org
> Sent: Tuesday, March 2, 2010 2:08:55 PM GMT -05:00 US/Canada Eastern
> Subject: Re: svn usage tips
>
> Let me get this straight, you're not talking about checking out a single
> project vs. the whole tree. You're talking about checking out a project, but
> not the externals directories? You can take a look at several things: *
> There's an --ignore-externals flag when you do a checkout. This prevents any
> externals directory from being checked out. * Take a look at the --depth
> switch. You can checkout a directory, without checking out the
> sub-directories, then just update the subdirectories you want. (Note:
> There's a --set-depth flag on the update command to override the setting on
> the checkout command. (See
> http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkoutsfor 
> more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM,
> Paul Decker wrote: > Hi list, > > > > I recently changed jobs and went from
> a cvs house to a svn house.   They > have many projects and have an
> extensive shared source base.   I would like > to know if there is a way to
> setup to check out a list of folders or > files.   In other words, for each
> project, I want to check out only files > that are directly related to that
> project rather than evey file which is in > the shared directory. > > > >
> ie. > > > > projects\ > > \display > > \display2 > > \display3 > > \comm > >
> \usb > > \tcp > > \keyboard > > \spi > > \i2c > > \flash > > \eeprom > > > >
> Some projects use {display, comm, keyboard, spi } while other projects use >
> {display, usb, spi, flash }   currently, the only way of working is to check
> > out all folders. > > > > Is there a better way to work? > > > > thanks, >
> > Paul > > -- David Weintraub qazw...@gmail.com
> Let me get this straight, you're not talking about checking out a single
> project vs. the whole tree. You're talking about checking out a project, but
> not the externals directories? You can take a look at several things: *
> There's an --ignore-externals flag when you do a checkout. This prevents any
> externals directory from being checked out. * Take a look at the --depth
> switch. You can checkout a directory, without checking out the
> sub-directories, then just update the subdirectories you want. (Note:
> There's a --set-depth flag on the update command to override the setting on
> the checkout command. (See
> http://subversion.apache.org/docs/release-notes/1.5.html#sparse-checkoutsfor 
> more information on the depth switch.) On Tue, Mar 2, 2010 at 1:07 PM,
> Paul Decker wrote: > Hi list, > > > > I recently changed jobs and went from
> a cvs house to a svn house.   They > have many projects and have an
> extensive shared source base.   I would like > to know if there is a way to
> setup to check out a list of folders or > files.   In other words, for each
> project, I want to check out only files > that are directly related to that
> project rather than evey file which is in > the shared directory. > > > >
> ie. > > > > projects\ > > \display > > \display2 > > \display3 > > \comm > >
> \usb > > \tcp > > \keyboard > > \spi > > \i2c > > \flash > > \eeprom > > > >
> Some projects use {display, comm, keyboard, spi } while other projects use >
> {display, usb, spi, flash }   currently, the only way of working is to check
> > out all folders. > > > > Is there a better way to work? > > > > thanks, >
> > Paul > > -- David Weintraub qazw...@gmail.com
>

Re: Tigris binary packages for Windows

[Johan Corveleyn]

On Tue, Mar 2, 2010 at 7:54 PM, Daniel Shahaf  wrote:
> David Darj wrote on Tue, 2 Mar 2010 at 19:42 +0100:
>> There is instructions how to build Win32 binaries in the INSTALL file.
>> However, I tried twice (once at work and once at home) and failed with
>> compilation errors. Maybe because of using wrong version of dependencies or
>> wrong parameters to the build scripts.
>> And I havn't had the time to track those errors down to their source.
>>
>> I have a virtual machine I can use for the build process.
>> I too would be very happy if DJ could come up with a detailed description of
>> his build process.
>> Then I would gladly take over and build upcoming versions for the community.
>>
>> /David
>>
> If you try to build and fail, feel free to post to this list and we'll help.
>
> There are a couple of other ways to build svn besides what's documented in
> INSTALL :-).  I posted to this list a makefile that I use (with VC
> express) for my windows build, and IIRC the tortoisesvn folks (and other
> windows clients) have their own build scripts too.
>
> (Oh, and I don't know if anyone ever tried to cross-compile svn windows
> binaries on other OSes.)
>
> Good luck!
>

I also whish you (or anyone who tries to build subversion on Windows)
good luck. It can be done, but it isn't easy. I for one spent a lot of
time getting it to work on my machine, just to experiment with some
simple things. Now I have a working build setup, but I wouldn't
consider it standard by any means (and don't have more time to invest
in standardizing this build).

I actually started from Daniel Shahaf's Makefile, which he mentioned
above. See my experiences here:
http://svn.haxx.se/users/archive-2009-09/0305.shtml

Regards,
Johan

Re: Tigris binary packages for Windows

[Mark Phippard]

On Tue, Mar 2, 2010 at 4:48 PM, Johan Corveleyn  wrote:

> I also whish you (or anyone who tries to build subversion on Windows)
> good luck. It can be done, but it isn't easy. I for one spent a lot of
> time getting it to work on my machine, just to experiment with some
> simple things. Now I have a working build setup, but I wouldn't
> consider it standard by any means (and don't have more time to invest
> in standardizing this build).
>
> I actually started from Daniel Shahaf's Makefile, which he mentioned
> above. See my experiences here:
> http://svn.haxx.se/users/archive-2009-09/0305.shtml

I do not want to jinx myself for the next time I have to setup a new
system, but I do not find it that difficult.  I have been building SVN
on Windows for years and have set it up on a number of new systems. I
usually get it all working right the first time now.

It is certainly a "pain in the ***" but it is not that hard.  The
worst part is just that building SVN means building a whole lot of
other software first and tracking down dependencies for those build
processes like Perl/Python that you might not otherwise have
installed.

Personally, I would steer people away from volunteering for this task
because I know what a pain it is.  Building the basic binaries is not
too hard, but doing it for all of the bindings and dealing with things
like providing different versions of the binaries built against
different Python versions or Apache versions gets to be a bit much.
Not to mention some of the variants in building in support for some of
the different SSL and authentication packages.  These are basically
the reasons I cannot see this project ever officially supporting any
specific binary.  It should really be the maintainer of the binary
that does the support because there are too many factors involved.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn usage tips

[David Weintraub]

On Tue, Mar 2, 2010 at 2:31 PM, Paul Decker  wrote:
> I am talking about checking out a single project, however the "projects" all
> use the same folders, like shared folders.  So when you do a get on the top
> level, you get all the files for every project rather than just the files
> for the project of interest
>

What does your repository directory structure look like? I don't need
a detailed picture. Just an overview.

It sounds like you're saying that the structure looks like this:

/project1
/project2
/project3
/common1
/common2
/common3
/common4


If you are working on /project1, you need to checkout folders
/common1, /common2, /common3, /common4 too.

If that's the case, you'll need to use --depth:

$ # Checks out the root project, but no folders
$ svn co --depth=empty svn://subversion/ workspace-project1
$ cd workspace-project1

$ #Now we have to "update" the missing folders
$ svn update --set-depth=infinity project1 common1 common2 common3 common4

This will checkout your project, and the needed shared folders. When
you do an update, it won't "update" the missing stuff.

A better way is to use "externals". Take a look at
. This
is the way shared folders are suppose to be used. That way, you can
set the version of the shared folder with the project. For example, it
is possible that the latest version of the shared folder might not be
compatible with the version of the project.

This way, you can checkout project1 and all the common folders will
automatically be checkout too.

-- 
David Weintraub
qazw...@gmail.com

Re: Programming a Watcher File

[Andrey Repin]

Greetings, David Weintraub!

> One of the tech leads wants to be able to program a watch file, so
> that when a certain set of developers change a particular file,
> certain other developers get notified. Thus, we need to be able to
> program what files, what developers do the commit, and what developers
> receive the notification. I'd like to do this, so this developer can
> maintain this file himself instead of me having to maintain it which
> means it can't be a text file on the Subversion server.

Sorry, my head is a bit crippled for now, and your post contains too much
cross-references to be understandable in my current state.
Could you please put it in simple terms, how you see your potential system
works?

> I'm working with something like this now. I have a configuration file
> where you setup the various parameters (specifying files via globbing
> or regex), who does the commit, and who receives the email. The
> configuration file sits in the source repository, so this tech lead
> has access to it.

> I was wondering if anyone already has a post-commit hook script like
> this already setup. I know there's one included in Subversion, but
> this one uses a text file that's accessible to the hook script and its
> setup isn't that flexible.

> If not, I'll finish up the one I'm working on.

If having a custom (and client-customizable) configuration is all you ever
want, there's a hint: hook script can access repository as easy as any other
local file. Just do "svn cat" on required file and parse it's content as
normal.

However, be very wary of access rights on the mentioned configuration file.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 03.03.2010, <7:35>

Sorry for my terrible english...

Re: strange problem with subversion merge

[J. Bakshi]

On 03/02/2010 07:48 PM, Giulio Troccoli wrote:
>   
>> 
>> svn merge -r 475:476 trunk/
>> `
>> 
>   
>> 
>> svn merge --dry-run -r 490:491 trunk/typo3conf/ branches/bug/
>> Skipped missing target: 'branches/bug/localconf.php'
>> ```
>> 
> But these commands are not the same.
>
> >From your previous email I understand the bug branch was created as a copy 
> >of trunk. What you're trying here is to merge the changes in trunk/typo3conf 
> >to a copy of trunk, instead of a copy of trunk/typo3conf.
>   

You are absolute correct. the bug branch is a copy of trunk and it has
been created to do the bug fixing. Once done then it should be allowed
to merge into trunk. Please suggest how can I achieve this. Meanwhile I
am going to five a read to the link you have mentioned here.

Thanks


> You seem to be very confused about merging. Maybe you should (re)read the 
> documenation. http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
>
>
> Linedata Services (UK) Ltd
> Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
> Registered in England and Wales No 3027851VAT Reg No 778499447
>
>
>
>
>
>   


-- 
জয়দীপ বক্সী

Re: strange problem with subversion merge

[J. Bakshi]

On 03/03/2010 11:04 AM, J. Bakshi wrote:
> On 03/02/2010 07:48 PM, Giulio Troccoli wrote:
>   
>>   
>> 
>>> 
>>> svn merge -r 475:476 trunk/
>>> `
>>> 
>>>   
>>   
>> 
>>> 
>>> svn merge --dry-run -r 490:491 trunk/typo3conf/ branches/bug/
>>> Skipped missing target: 'branches/bug/localconf.php'
>>> ```
>>> 
>>>   
>> But these commands are not the same.
>>
>> >From your previous email I understand the bug branch was created as a copy 
>> >of trunk. What you're trying here is to merge the changes in 
>> >trunk/typo3conf to a copy of trunk, instead of a copy of trunk/typo3conf.
>>   
>> 
> You are absolute correct. the bug branch is a copy of trunk and it has
> been created to do the bug fixing. Once done then it should be allowed
> to merge into trunk. Please suggest how can I achieve this. Meanwhile I
> am going to five a read to the link you have mentioned here.
>
> Thanks
>   

Dear Giulio Troccoli,

Thanks a lot. I have gone through the link you have provided and now the
merge is working well :-) That link gives very good clarification. Do
you have any experience to work with esvn or aptana ? I don't  know how
merging works with these GUI based tool and looking for the info.
Anyways, thanks a lot once more.

Wish you a great day.

-- 
জয়দীপ বক্সী