Re: 'Could not get next bucket brigade' error

[Boyandin Konstantin]

06.03.11, 20:00, "Nico Kadel-Garcia" :

> On Sun, Mar 6, 2011 at 7:22 AM, Andy Levy  wrote:
>  > On Sat, Mar 5, 2011 at 22:34, Konstantin Boyandin  
> wrote:
>  >> Hello,
>  >>
>  >> Setup: there's a server where Subversion repository is located (working
>  >> via Apache backend), OS CentOS 5.5, Subversion installed as RPM
>  >> subversion-1.4.2-4.el5_3.1
>  
>  Red Hat has published subversion-1.6.11 for RHEL 5.6, and you can grab
>  and recompile it from your nearest Red Hat SRPM mirror
>  (http://mirrors.kernel.org/redhat is pretty good.) CentOS 5.6 has been
>  taking a while to release, so it's not published for CentOS yet.

It looks like the optimal solution in case of CentOS 5.5

>  But there is also the RPMforge release of subversion-1.6.15 at
>  http://rpmrepo.org/RPMforge/. Enjoy, I put up that one (based on
>  variious previous releases.) I'd urge you to upgrade, ASAP, for a lot
>  of *other* reasons.

Thanks, but the above repository doesn't provide 64-bit version of the package.

Sincerely,
Konstantin

external diff and diff3 tools

[Sébastien Paumier]

Hello,
I have to deal with a special file format representing a graph. To do that, I 
have to write my own diff and diff3, but I did not figure out how to invoke my 
own programs only for my special file type, since those files are mixed with 
other file types on the svn server. Is there a way to adjust the values given to 
--diff-cmd and --diff3-cmd in the [auto-props] section of the config file on the 
basis of the file extension ? If not, would it be possible to consider a special 
return value from external diff and diff3 that would mean "this job was not for 
me, use the default tool" ?


Best regards,
Sébastien Paumier

Failed SVN Verify Logs

[Jules Herr]

Hi,

I had a failed SVN VERIFY and am submitting the log files as directed by the
application. Any and all help is greatly appreciated!

Thanks
Jules



Here is the screen shot and log files of the svnadmin verify which I did in
Windows against the kxsrc Subversion repository








-- 

Jules Herr
Technology Solutions Provider
jh...@inmedius.com
skpe: jules.herr
<>

svn-crash-log20110314092356.log
Description: Binary data


svn-crash-log20110314092356.dmp
Description: Binary data

Merging from foreign repositories

[Christoph Bartoschek]

Hi,

I would like to merge all changes in a directory from repository A to a 
directory in repository B.

My idea was to do a loop over all iterations and merge them to dirB:

svn merge -c rev file:///path/to/rep/A/dirA  dirB

My problem is that for the revision where dirA is created in repositoryA 
nothing is done. The next revision then fails because it misses a directory:

$ svn merge -r 0:1 file:///path/to/rep/A/dirA .
$ svn merge -r 1:2 file:///path/to/rep/A/dirA .
--- Merging (from foreign repository) r2 into '.':
   C utils
Summary of conflicts:
  Tree conflicts: 1


You see that the first command does nothing although dirA and lots of subdirs 
were created in revision 1.

How can this be fixed?

Christoph

Re: Merging from foreign repositories

[Stefan Sperling]

On Mon, Mar 14, 2011 at 04:08:57PM +0100, Christoph Bartoschek wrote:
> Hi,
> 
> I would like to merge all changes in a directory from repository A to a 
> directory in repository B.
> 
> My idea was to do a loop over all iterations and merge them to dirB:
> 
> svn merge -c rev file:///path/to/rep/A/dirA  dirB
> 
> My problem is that for the revision where dirA is created in repositoryA 
> nothing is done.

> You see that the first command does nothing although dirA and lots of subdirs 
> were created in revision 1.

The addition of dirA is a change on the *parent* of dirA.

So merge the parent folder into the target's parent folder first,
preferrably using a two-URL merge (Last time I tried this, with TortoiseSVN,
it would only work with a two-URL merge. I'm not sure if the CLI client
has the same requirement. But since both use the same libraries that is not
unlikely):

svn merge file:///path/to/rep/A/@rev-1 file:///path/to/rep/A/@rev parent-dir

This will add dirA into parent-dir. Commit this.

Next, you could experiment with renaming dirA to dirB.
But if you ever merge at a higher level in the tree, so that changes
made upstream in dirA appear as part of the diff, you will get tree
conflicts since dirA won't be found at your end.
So not renaming it might save you some headaches later.
I'd recommend keeping the name.

Now, the following revs can apply cleanly.
There is no need to loop over the revs, you can apply the entire
range at once, giving you single commit that contains all the changes
made upstream.

svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD dirA
or if you decided to rename:
svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD dirB

If you have a real need to cherry-pick individual changes merged from
the foreign repository to branches in your own repository, you will
need to loop over all the revs, of course, and merge them individually.

Note that there is no merge tracking with foreign repos merges,
so make sure to note which revisions have already been merged from
the foreign repository (e.g. in the log message).

Re: Merging from foreign repositories

[Christoph Bartoschek]

Am Montag, 14. März 2011 schrieb Stefan Sperling:
> On Mon, Mar 14, 2011 at 04:08:57PM +0100, Christoph Bartoschek wrote:
> > Hi,
> > 
> > I would like to merge all changes in a directory from repository A to a
> > directory in repository B.
> > 
> > My idea was to do a loop over all iterations and merge them to dirB:
> > 
> > svn merge -c rev file:///path/to/rep/A/dirA  dirB
> > 
> > My problem is that for the revision where dirA is created in repositoryA
> > nothing is done.
> > 
> > You see that the first command does nothing although dirA and lots of
> > subdirs were created in revision 1.
> 
> The addition of dirA is a change on the *parent* of dirA.
> 
> So merge the parent folder into the target's parent folder first,
> preferrably using a two-URL merge (Last time I tried this, with
> TortoiseSVN, it would only work with a two-URL merge. I'm not sure if the
> CLI client has the same requirement. But since both use the same libraries
> that is not unlikely):
> 
> svn merge file:///path/to/rep/A/@rev-1 file:///path/to/rep/A/@rev
> parent-dir
> 
> This will add dirA into parent-dir. Commit this.
> 
> Next, you could experiment with renaming dirA to dirB.
> But if you ever merge at a higher level in the tree, so that changes
> made upstream in dirA appear as part of the diff, you will get tree
> conflicts since dirA won't be found at your end.
> So not renaming it might save you some headaches later.
> I'd recommend keeping the name.
> 
> Now, the following revs can apply cleanly.
> There is no need to loop over the revs, you can apply the entire
> range at once, giving you single commit that contains all the changes
> made upstream.
> 
> svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD
> dirA or if you decided to rename:
> svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD
> dirB
> 
> If you have a real need to cherry-pick individual changes merged from
> the foreign repository to branches in your own repository, you will
> need to loop over all the revs, of course, and merge them individually.
> 
> Note that there is no merge tracking with foreign repos merges,
> so make sure to note which revisions have already been merged from
> the foreign repository (e.g. in the log message).


Hi,

thanks for your suggestion. But the commit that created dirA also created lots 
of other directories. I am only interessted in dirA. 

I wrote that I want to do this incrementally because I would like to replicate 
each change in directory dirA of repository A to directory dirB of repository 
B with a commit hook.

Apparently this does not work with the commit that creates dirA. It seems as 
if subversion is not able to do this. I will have to do this manually.

Unfortunately the automatic merging still does not work after fixing the 
creation of dirA. I describe it in another main.

Christoph

Re: Merging from foreign repositories

[Daniel Shahaf]

Christoph Bartoschek wrote on Mon, Mar 14, 2011 at 16:08:57 +0100:
> Hi,
> 
> I would like to merge all changes in a directory from repository A to a 
> directory in repository B.
> 
> My idea was to do a loop over all iterations and merge them to dirB:
> 
> svn merge -c rev file:///path/to/rep/A/dirA  dirB
> 
> My problem is that for the revision where dirA is created in repositoryA 
> nothing is done. The next revision then fails because it misses a directory:
> 
> $ svn merge -r 0:1 file:///path/to/rep/A/dirA .
> $ svn merge -r 1:2 file:///path/to/rep/A/dirA .
> --- Merging (from foreign repository) r2 into '.':
>C utils
> Summary of conflicts:
>   Tree conflicts: 1
> 
> 
> You see that the first command does nothing although dirA and lots of subdirs 
> were created in revision 1.
> 
> How can this be fixed?
> 

svn merge -c 1 file:///path/to/rep/A/

(i.e., for the revision creating the dir, give the parent as the target)

> Christoph

Re: external diff and diff3 tools

[Daniel Shahaf]

I suppose you could write a wrapper diff3 tool that invokes either
/usr/bin/diff3 or your diff3 tool depending on the files it's invoked
for?

Not saying it's ideal, but it'll work today (not when 1.7 is released).

Sébastien Paumier wrote on Mon, Mar 14, 2011 at 12:59:23 +0100:
> Hello,
> I have to deal with a special file format representing a graph. To
> do that, I have to write my own diff and diff3, but I did not figure
> out how to invoke my own programs only for my special file type,
> since those files are mixed with other file types on the svn server.
> Is there a way to adjust the values given to --diff-cmd and
> --diff3-cmd in the [auto-props] section of the config file on the
> basis of the file extension ? If not, would it be possible to
> consider a special return value from external diff and diff3 that
> would mean "this job was not for me, use the default tool" ?
> 
> Best regards,
> Sébastien Paumier

Re: 'Could not get next bucket brigade' error

[Kris Deugau]

Boyandin Konstantin wrote:

06.03.11, 20:00, "Nico Kadel-Garcia":

  But there is also the RPMforge release of subversion-1.6.15 at
  http://rpmrepo.org/RPMforge/. Enjoy, I put up that one (based on
  variious previous releases.) I'd urge you to upgrade, ASAP, for a lot
  of *other* reasons.


Thanks, but the above repository doesn't provide 64-bit version of the package.


Not sure where you're looking, but you're missing something:

[kdeugau@lilbro ~]$ rpm -q subversion
subversion-1.6.15-0.1.el5.rfx
[kdeugau@lilbro ~]$ cat /etc/redhat-release
CentOS release 5.5 (Final)

(The .rfx in the release number indicates "RPMForge Extras" - packages 
that will overwrite the stock CentOS/RHEL ones.)


If you prefer to direct-download the package files yourself, they're all 
in here:


http://packages.sw.be/subversion/

-kgd

Merging from a foreign repository and svn:id keyword

[Christoph Bartoschek]

Hi,

I would like to merge the changes of a directory in repository A to a 
directory in repository B. My problem is that several merges fail because of 
the id keywords.

Svn diff for example shows:

-/*
-** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $
-**
-** $Locker:  $
-*/
+/* $Id$ */

The removed Id line cannot be found in repository B because a different user 
created it. It looks like:

** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $


The merge then fails with a conflict because it cannot find the line of the 
diff.  How can I let merge ignore conflicts that arise because of expanded Id 
lines?

Or how to prevent Id expansion locally and in the diffs?

Christoph

Re: Hosting multiple subdomains with a common SVNParentPath under apache

[Daniel Shahaf]

Ryan Schmidt wrote on Thu, Mar 10, 2011 at 20:09:31 -0600:
> On Mar 10, 2011, at 15:17, Daniel F. Garcia wrote:
> 
> > This is a good solution, but I have 2 additional requirements
> > * I have >100 subdomains and I want to save time setting them up (ok, I 
> > could script this)
> > * I need to be able to add subdomains without restarting apache
> > 
> > The 2nd requirement is why I used the *.mydomain.com alias and used the 
> > SVNParentPath directive.
> 
> Sorry, Daniel, I don't know a way to accomplish all those objectives. The 
> only options Subversion provides are:
> 
>  * SVNPath: host a single repository at a URL
>  * SVNParentPath: host multiple repositories under a parent URL
> 

Thus, this is really an httpd question not an svn question.  The
@httpd.apache.org lists might be the better forum.

> There is no provision for using SVNParentPath with the repository name coming 
> from the hostname, only from a directory component in the URL.
> 
> You cannot use mod_rewrite or similar to fake this. Subversion clients do not 
> follow HTTP redirects.
> 

They will in 1.7: 
http://subversion.apache.org/docs/release-notes/1.7#http-redirects

> The only way I know to accomplish the functionality you want is to define 
> each subdomain as its own VirtualHost, either manually or via a script you 
> write. You will have to restart Apache when making changes, though a graceful 
> restart shouldn't impact you too much.
> 
> 
> 

Re: Merging from foreign repositories

[Stefan Sperling]

On Mon, Mar 14, 2011 at 05:05:14PM +0100, Christoph Bartoschek wrote:
> thanks for your suggestion. But the commit that created dirA also created 
> lots 
> of other directories. I am only interessted in dirA. 

Then let's just agree that the other stuff added in that commit
is a merge conflict. So you svn revert -R all of that stuff after
performing the merge and before committing the merge result.

> I wrote that I want to do this incrementally because I would like to 
> replicate 
> each change in directory dirA of repository A to directory dirB of repository 
> B with a commit hook.

Since you're writing hook scripts, it sounds like you have a way to get 
an incremental dump file of each revision committed to repository A.
If so, why not load them into repository B using svnadmin load?

svnadmin dump --incremental --deltas -rREV /path/to/reposA > REV.dump
svnadmin load --parent-dir /branches/fromA /path/to/reposB < REV.dump

> Apparently this does not work with the commit that creates dirA. It seems as 
> if subversion is not able to do this. I will have to do this manually.

You can probably write your hook script to be smart enough to do it. 
But I suppose in your situation the dump/load approach is easier than
trying to play tricks with merging.

Re: external diff and diff3 tools

[Stefan Sperling]

On Mon, Mar 14, 2011 at 06:08:11PM +0200, Daniel Shahaf wrote:
> I suppose you could write a wrapper diff3 tool that invokes either
> /usr/bin/diff3 or your diff3 tool depending on the files it's invoked
> for?
> 
> Not saying it's ideal, but it'll work today (not when 1.7 is released).

Ways of interfacing with externals diff tools should be improved.

I like the suggestion of having a way to tell svn "you just tried the
external diff but that didn't work so use internal diff please".
That's much easier and straightforward than devising clever schemes
for selecting a diff tool based on the value of some svn: property
or filename extension, for instance.

> Sébastien Paumier wrote on Mon, Mar 14, 2011 at 12:59:23 +0100:
> > Hello,
> > I have to deal with a special file format representing a graph. To
> > do that, I have to write my own diff and diff3, but I did not figure
> > out how to invoke my own programs only for my special file type,
> > since those files are mixed with other file types on the svn server.
> > Is there a way to adjust the values given to --diff-cmd and
> > --diff3-cmd in the [auto-props] section of the config file on the
> > basis of the file extension ? If not, would it be possible to
> > consider a special return value from external diff and diff3 that
> > would mean "this job was not for me, use the default tool" ?
> > 
> > Best regards,
> > Sébastien Paumier

Re: Merging from foreign repositories

[Christoph Bartoschek]

Am Montag, 14. März 2011 schrieb Stefan Sperling:
> On Mon, Mar 14, 2011 at 05:05:14PM +0100, Christoph Bartoschek wrote:
> > thanks for your suggestion. But the commit that created dirA also created
> > lots of other directories. I am only interessted in dirA.
> 
> Then let's just agree that the other stuff added in that commit
> is a merge conflict. So you svn revert -R all of that stuff after
> performing the merge and before committing the merge result.
> 
> > I wrote that I want to do this incrementally because I would like to
> > replicate each change in directory dirA of repository A to directory
> > dirB of repository B with a commit hook.
> 
> Since you're writing hook scripts, it sounds like you have a way to get
> an incremental dump file of each revision committed to repository A.
> If so, why not load them into repository B using svnadmin load?
> 
> svnadmin dump --incremental --deltas -rREV /path/to/reposA > REV.dump
> svnadmin load --parent-dir /branches/fromA /path/to/reposB < REV.dump
> 
> > Apparently this does not work with the commit that creates dirA. It seems
> > as if subversion is not able to do this. I will have to do this
> > manually.
> 
> You can probably write your hook script to be smart enough to do it.
> But I suppose in your situation the dump/load approach is easier than
> trying to play tricks with merging.

I do not have admin access to repository B. I can only check in into the 
parent directory of dirB and below.

Christoph

Re: Merging from a foreign repository and svn:id keyword

[Nico Kadel-Garcia]

On Mon, Mar 14, 2011 at 12:11 PM, Christoph Bartoschek
 wrote:
> Hi,
>
> I would like to merge the changes of a directory in repository A to a
> directory in repository B. My problem is that several merges fail because of
> the id keywords.
>
> Svn diff for example shows:
>
> -/*
> -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $
> -**
> -** $Locker:  $
> -*/
> +/* $Id$ */
>
> The removed Id line cannot be found in repository B because a different user
> created it. It looks like:
>
> ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $
>
>
> The merge then fails with a conflict because it cannot find the line of the
> diff.  How can I let merge ignore conflicts that arise because of expanded Id
> lines?
>
> Or how to prevent Id expansion locally and in the diffs?
>
> Christoph

The easiest way is to *NOT* use Id and similar keyword expansion, at
all. That's the Linux kernel approach. They can be very, very nasty
indeed to parse and merge.

Second, pick a single format for comments and keywords and *stick with
it*. The switch in syntax from multi-line commented entries to single
line comment entries is biting you hard here and confusing your diffs
noticeably.

Sadly, you can't outsmart the ability of people to tweak formats. The
simplest way is to resolve the merge manually.

Re: Merging from foreign repositories

[Stefan Sperling]

On Mon, Mar 14, 2011 at 05:53:04PM +0100, Christoph Bartoschek wrote:
> Am Montag, 14. März 2011 schrieb Stefan Sperling:
> > You can probably write your hook script to be smart enough to do it.
> > But I suppose in your situation the dump/load approach is easier than
> > trying to play tricks with merging.
> 
> I do not have admin access to repository B. I can only check in into the 
> parent directory of dirB and below.

That's unfortunate.

This won't help you right now, but once Subversion 1.7 has been released,
you can use the new svnrdump tool to do this. It doesn't require admin
access because it works with any remote repository (and can also load
dump files into them):
http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump

Re: Merging from a foreign repository and svn:id keyword

[Stefan Sperling]

On Mon, Mar 14, 2011 at 05:11:03PM +0100, Christoph Bartoschek wrote:
> Hi,
> 
> I would like to merge the changes of a directory in repository A to a 
> directory in repository B. My problem is that several merges fail because of 
> the id keywords.
> 
> Svn diff for example shows:
> 
> -/*
> -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $

It looks like the above Id expansion is from CVS, not from Subversion?
I'd guess the source repository does not have svn:keywords set no this file,
because otherwise it would look different.

> -**
> -** $Locker:  $
> -*/
> +/* $Id$ */
> The removed Id line cannot be found in repository B because a different user 
> created it. It looks like:
> 
> ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $
> 
> 
> The merge then fails with a conflict because it cannot find the line of the 
> diff.  How can I let merge ignore conflicts that arise because of expanded Id 
> lines?

Does the file have an svn:keyword property set in your repository?
If so, have you tried removing it?

Maybe this is due to auto-props settings in your local configuration file?
 
> Or how to prevent Id expansion locally and in the diffs?

It's controlled via svn:keywords properties:
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

Re: Merging from a foreign repository and svn:id keyword

[Christoph Bartoschek]

Am Montag, 14. März 2011 schrieb Nico Kadel-Garcia:
> On Mon, Mar 14, 2011 at 12:11 PM, Christoph Bartoschek
> 
>  wrote:
> > Hi,
> > 
> > I would like to merge the changes of a directory in repository A to a
> > directory in repository B. My problem is that several merges fail because
> > of the id keywords.
> > 
> > Svn diff for example shows:
> > 
> > -/*
> > -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $
> > -**
> > -** $Locker:  $
> > -*/
> > +/* $Id$ */
> > 
> > The removed Id line cannot be found in repository B because a different
> > user created it. It looks like:
> > 
> > ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $
> > 
> > 
> > The merge then fails with a conflict because it cannot find the line of
> > the diff.  How can I let merge ignore conflicts that arise because of
> > expanded Id lines?
> > 
> > Or how to prevent Id expansion locally and in the diffs?
> > 
> > Christoph
> 
> The easiest way is to *NOT* use Id and similar keyword expansion, at
> all. That's the Linux kernel approach. They can be very, very nasty
> indeed to parse and merge.
> 
> Second, pick a single format for comments and keywords and *stick with
> it*. The switch in syntax from multi-line commented entries to single
> line comment entries is biting you hard here and confusing your diffs
> noticeably.
> 
> Sadly, you can't outsmart the ability of people to tweak formats. The
> simplest way is to resolve the merge manually.


I would like to get rid of Id expansion but I have to use what our group has 
agreed on.

It would help me if I could create a checkout where svn:keywords are not 
expanded and if I could tell svn merge to also not expand the keywords.  Is 
this somehow possible? 

If you tell me where to look I could also compile a svn client version for me 
that prevents the expansion. Basically I think that it should be a one-liner 
to prevent the expansion.

Christoph

Re: Merging from a foreign repository and svn:id keyword

[Christoph Bartoschek]

Am Montag, 14. März 2011 schrieb Stefan Sperling:
> On Mon, Mar 14, 2011 at 05:11:03PM +0100, Christoph Bartoschek wrote:
> > Hi,
> > 
> > I would like to merge the changes of a directory in repository A to a
> > directory in repository B. My problem is that several merges fail because
> > of the id keywords.
> > 
> > Svn diff for example shows:
> > 
> > -/*
> > -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $
> 
> It looks like the above Id expansion is from CVS, not from Subversion?
> I'd guess the source repository does not have svn:keywords set no this
> file, because otherwise it would look different.

Oh, you are right, this is an Id line from TCCS our previous software 
management system. 

I guess I have to fix this manually.
 
> > -**
> > -** $Locker:  $
> > -*/
> > +/* $Id$ */
> > The removed Id line cannot be found in repository B because a different
> > user created it. It looks like:
> > 
> > ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $
> > 
> > 
> > The merge then fails with a conflict because it cannot find the line of
> > the diff.  How can I let merge ignore conflicts that arise because of
> > expanded Id lines?
> 
> Does the file have an svn:keyword property set in your repository?
> If so, have you tried removing it?
> 
> Maybe this is due to auto-props settings in your local configuration file?
> 
> > Or how to prevent Id expansion locally and in the diffs?
> 
> It's controlled via svn:keywords properties:
> http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.
> html

The keyword is set and I do not want to change it because I just want to 
import the changes from repository A to repository B. The guys that set the 
keyword definitively want to see it. 

I want to disable the expansion only for my workarea where I merge the changes 
from repository A to repository B.

If the code is then checked out from repository B the expansion should take 
place with the new revision numbers.


Christoph

Re: Failed SVN Verify Logs

[Jules Herr]

Yes we're using the binaries for Collabnet, not exactly sure which version
it is - is there an easy way to determine?

Not sure if I can access revision 607,  is there a way to determine what
files are in a particular revision?

It appears I can run verification on all revisions 1-606 and I'm running a
verify on 608-8968 right now, seems to be running OK.

Users have had no problems accessing the repository, and this problem has
only made itself evident since we've tried to move our SVN repo via dump
files to a new server.

I'm currently attempting a hot-copy as this has apparently fixed another
users repo who was experiencing similar symptoms:

http://jim.bernatowicz.net/fix-corrupt-svn-repository-fails-svn-verify-hotcopy-backup


Thanks
jules




On Mon, Mar 14, 2011 at 1:39 PM, ankush chadha
wrote:

> Which subversion binaries are you using? Are these the ones from Collabnet?
>
> Can you access revision 607? Can you also try resuming the verification
> process from revision 607?
>
> Ankush
>
>
> --
> *From:* Jules Herr 
> *To:* users@subversion.apache.org
> *Sent:* Mon, March 14, 2011 10:42:16 AM
> *Subject:* Failed SVN Verify Logs
>
> Hi,
>
> I had a failed SVN VERIFY and am submitting the log files as directed by
> the application. Any and all help is greatly appreciated!
>
> Thanks
> Jules
>
>
>
> Here is the screen shot and log files of the svnadmin verify which I did in
> Windows against the kxsrc Subversion repository
>
>
>
>
>
>
>
>
> --
>
> Jules Herr
> Technology Solutions Provider
> jh...@inmedius.com
> skpe: jules.herr
>
>
>
>


-- 

Jules Herr
Technology Solutions Provider
jh...@inmedius.com
skpe: jules.herr

Out of memory issue with svn merging

[richard.everett]

Hi,
 
We are seeing the following error when trying to perform a command-line
svn merge with Subversion 1.6.9 under 32 bit Windows XP.

Out of memory - terminating application.

This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.

Inspecting Windows task manager around this time reveals the following
memory usage

 

The peak memory usage of the svn.exe process is in excess of 1.8GB.

As an aside, we get the same result when trying to perform the merge
using TortoiseSVN.

We are trying to perform the merge from the root level of our
repository. The total file size (on a developer machine) of the
repository is around 3GB.

This is the first time that we are attempting a root-level merge. Are we
hitting an internal svn limit?

<>Visit our website at http://www.ubs.com 

This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system. 

E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission. 
If verification is required please request a hard-copy version. This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments. 

UBS Limited is a company limited by shares incorporated in the United 
Kingdom registered in England and Wales with number 2035362. 
Registered office: 1 Finsbury Avenue, London EC2M 2PP.  UBS Limited 
is authorised and regulated by the Financial Services Authority. 

UBS AG is a public company incorporated with limited liability in 
Switzerland domiciled in the Canton of Basel-City and the Canton of 
Zurich respectively registered at the Commercial Registry offices in 
those Cantons with Identification No: CH-270.3.004.646-4 and having 
respective head offices at Aeschenvorstadt 1, 4051 Basel and 
Bahnhofstrasse 45, 8001 Zurich, Switzerland.  Registered in the 
United Kingdom as a foreign company with No: FC021146 and having a 
UK Establishment registered at Companies House, Cardiff, with No:  
BR 004507.  The principal office of UK Establishment: 1 Finsbury Avenue, 
London EC2M 2PP.  In the United Kingdom, UBS AG is authorised and 
regulated by the Financial Services Authority.

UBS reserves the right to retain all messages. Messages are protected 
and accessed only in legally justified cases. 

subclipse != cvs eclipse, or how to "reject a change" ? svn API guilty?

[rupert.thurner]

the eclipse cvs client allows to reject a change by simply clicking
"mark the local file as merged", and commit it.

There are multiple enhancement requests filed against sublicpse which
get rejected because "svn does not offer such a feature via API" and
"we (subclipse) do not tinker with your files, except via svn API",
see e.g. http://subclipse.tigris.org/issues/show_bug.cgi?id=761.

Alone from the number of requirements its seems pretty clear that
users do want this feature. But I am wondering what the correct place
to implement would be? Or to put it in other words, if one would
implement the feature into the svn command line client, where would
this feature go? above or below the API?

rupert.

RE: Out of memory issue with svn merging

[Chris Evans]

Without a 32bit executable being large address aware it's not going to be able 
to use more than around 2GB of virtual address space. Ideally you'd use a 64bit 
client on a 64bit OS. If that's not possible then you can maybe squeeze a bit 
more out of a 32bit client by forcing it to use up to 3GB.

Use MASM32 to apply the /LARGEADDRESSAWARE option to your client exe.   
editbin.exe /LARGEADDRESSAWARE \path\to\svn.exe
Set /3GB in your boot.ini

See:
http://support.microsoft.com/kb/833721
http://masm32.com/
http://msdn.microsoft.com/en-us/library/wz223b1z(v=vs.80).aspx



*bypass*

RE: Assistance with SVN layout from CVS

[Bob Archer]

> Hi, I have been using CVS since 1998 and I am now finally moving to
> SVN. After having studied SVN for the last few weeks, getting the
> server prepared and working with clients, both console and GUI, I
> think I can use the accumulated experience for a simple migration
> and
> new SVN layout.
> 
> We have had many revisions since 1998 and I don't think its worth
> the
> effort to try to re-record all this under SVN.  But what I have
> done
> is under CVS is checked out l the projects from the last 10
> revision
> tags into their own folders by tag name:
> 
> \rev6_3_452_5
> \rev6_3_452_6
> \rev6_3_452_7
> \rev6_3_452_8
> \rev6_3_452_9
> \rev6_3_453_1
> \rev6_3_453_2
> \rev6_3_453_3  last official release
> \rev6_3_453_4  next pending official release
> \rev6_3_453_5  I would consider this a "branch" w/ one project
> off
> 453_3
> 
> There are at least in total 100+ projects in the total system, but
> they are not all in each tagged revision, only whats changed for
> that
> release. i.e, 453_5 has one project with some exploratory code. It
> was
> by mistake (pre-mature) that it was tagged since this code will not
> be
> used, but I would like to see how that is applied via SVN branches.
> 
> I "almost" got the idea of the SVN branch, tags and truck but I am
> finding myself a little lost which way to go here.
> 
> I can really use some help here.  The above would probably be the
> simplistic I can make it to go forward and was hoping to see how
> others would lay it out with the SVN framework.  I now SVN offers
> flexibility and one can move things around later, but what would
> you
> suggest here?
> 
> I decided to post because after I checked out the revision tags, I
> was
> wondering if I should do something like:
> 
>for each revision (upto 453.3)
>   - import revision into trunk
>   - do a "cheap copy" of current trunk into tags
> 
> with the idea that I would end up with:
> 
>- branch
>how do I get that one project 453.5 exploratory code here?
>- tags
>   \rev6_3_452_5
>   \rev6_3_452_6
>   \rev6_3_452_7
>   \rev6_3_452_8
>   \rev6_3_452_9
>   \rev6_3_453_1
>   \rev6_3_453_2
>   \rev6_3_453_3
>- trunk
>   \current   < current would be 453.3
> 
> and if this the basis for my new SVN layout and then when when I
> done
> with 453.4 development I can commit into the trunk and also create
> a
> cheap copy into tags "rev6-3_453_4"
> 
> I speaking as I know what I am doing. :) But maybe I am now.  Note,
> it
> is critical what we maintain a version numbering like 6.4.453.4
> (label
> wise) as that is how the product has worked since 1998. I would not
> how the SVN revision # only idea would apply yet.  I don't use the
> CVS
> revision numbers eithers. Only tags.
> 
> I hope I can get some input here. Thanks.

I would start with your repository empty. Create your trunk / branches /tags in 
it.

Then I would check-out trunk to a folder.

Once that is checked out I would copy the contents of \rev6_3_452_5 to the 
working copy folder. Do an 

svn add . 

then submit

svn ci -m "Initial import of source"

Once I have done this I would create the tag:

svn cp ~/trunk ~/tags/rev6_3_452_5

from there I would copy the contents of \rev3_452_6 into the working copy... 
then do an svn add. Also do a compare of the files and see if any files in the 
older rev no longer exist in the newer rev and delete them. Once that is done 
do your commit and tag.

Keep doing this until you have gotten to the contents of rev6_453_3 into the 
working copy, hence trunk. Now create your branch:

svn cp ~/trunk ~/branch/rev6_3_453_5

No check out that branch and put the source for _5 into it an commit. 

I think that will get you where you want to be, without having multiple copies 
of your projects in your repository and just using the cheap copies of svn.

Also, this all assumes the procedure of release from trunk with future versions 
in branches. (Not my favorite way to go but many people us it.)

BOb

Re: Hosting multiple subdomains with a common SVNParentPath under apache

[Ryan Schmidt]

On Mar 14, 2011, at 11:15, Daniel Shahaf wrote:

>> You cannot use mod_rewrite or similar to fake this. Subversion clients do 
>> not follow HTTP redirects.
> 
> They will in 1.7: 
> http://subversion.apache.org/docs/release-notes/1.7#http-redirects

Neat! I see Subversion will in 1.7 follow permanent redirects but still error 
on temporary redirects. What was the reason for not following temporary 
redirects?

Re: subclipse != cvs eclipse, or how to "reject a change" ? svn API guilty?

[Ryan Schmidt]

On Mar 14, 2011, at 13:57, rupert.thurner wrote:

> the eclipse cvs client allows to reject a change by simply clicking
> "mark the local file as merged", and commit it.
> 
> There are multiple enhancement requests filed against sublicpse which
> get rejected because "svn does not offer such a feature via API" and
> "we (subclipse) do not tinker with your files, except via svn API",
> see e.g. http://subclipse.tigris.org/issues/show_bug.cgi?id=761.
> 
> Alone from the number of requirements its seems pretty clear that
> users do want this feature. But I am wondering what the correct place
> to implement would be? Or to put it in other words, if one would
> implement the feature into the svn command line client, where would
> this feature go? above or below the API?

Perhaps you could begin by explaining what the feature is? For the benefit of 
those of us who are not familiar with Eclipse CVS or its "mark the local file 
as merged" feature.

Re: subclipse != cvs eclipse, or how to "reject a change" ? svn API guilty?

[rupert.thurner]

On Mar 14, 9:38 pm, Ryan Schmidt 
wrote:
> On Mar 14, 2011, at 13:57, rupert.thurner wrote:
>
> > the eclipse cvs client allows to reject a change by simply clicking
> > "mark the local file as merged", and commit it.
>
> > There are multiple enhancement requests filed against sublicpse which
> > get rejected because "svn does not offer such a feature via API" and
> > "we (subclipse) do not tinker with your files, except via svn API",
> > see e.g.http://subclipse.tigris.org/issues/show_bug.cgi?id=761.
>
> > Alone from the number of requirements its seems pretty clear that
> > users do want this feature. But I am wondering what the correct place
> > to implement would be? Or to put it in other words, if one would
> > implement the feature into the svn command line client, where would
> > this feature go? above or below the API?
>
> Perhaps you could begin by explaining what the feature is? For the benefit of 
> those of us who are not familiar with Eclipse CVS or its "mark the local file 
> as merged" feature.

a gui tool like eclipse cvs, and also tortoise svn i think, allow a
visual compare of an incoming change. if the change is not good, one
can "mark" the local copy as the new version, and commit it over the
version in the repository.

subclipse allows this only if the local file is modified as well.

if the local file is not modified, it is epected that you _have to_
update the remote version, roll back somehow to the previous state,
and commit it. i.e. no support whatsoever by the tool. mark phippard
argues that this is the right way to do as subversion does not offer
an api call to mark the local version as changed, if i understand his
comment correctly in the subclipse issue 761.

rupert.

Re: Merging from a foreign repository and svn:id keyword

[Stefan Sperling]

On Mon, Mar 14, 2011 at 06:33:13PM +0100, Christoph Bartoschek wrote:
> The keyword is set and I do not want to change it because I just want to 
> import the changes from repository A to repository B. The guys that set the 
> keyword definitively want to see it. 
> 
> I want to disable the expansion only for my workarea where I merge the 
> changes 
> from repository A to repository B.
> 
> If the code is then checked out from repository B the expansion should take 
> place with the new revision numbers.

Sorry, but keyword expansion cannot be turned off at the moment.

In Subversion 1.7 it will be possible to disable it for 'svn export'.
But this hasn't been implemented for other subcommands yet.

I'm afraid that "Patches welcome" is my best answer...

Re: subclipse != cvs eclipse, or how to "reject a change" ? svn API guilty?

[Mark Phippard]

On Mon, Mar 14, 2011 at 4:38 PM, Ryan Schmidt
 wrote:
>
> On Mar 14, 2011, at 13:57, rupert.thurner wrote:
>
>> the eclipse cvs client allows to reject a change by simply clicking
>> "mark the local file as merged", and commit it.
>>
>> There are multiple enhancement requests filed against sublicpse which
>> get rejected because "svn does not offer such a feature via API" and
>> "we (subclipse) do not tinker with your files, except via svn API",
>> see e.g. http://subclipse.tigris.org/issues/show_bug.cgi?id=761.
>>
>> Alone from the number of requirements its seems pretty clear that
>> users do want this feature. But I am wondering what the correct place
>> to implement would be? Or to put it in other words, if one would
>> implement the feature into the svn command line client, where would
>> this feature go? above or below the API?
>
> Perhaps you could begin by explaining what the feature is? For the benefit of 
> those of us who are not familiar with Eclipse CVS or its "mark the
> local file as merged" feature.

SVN 1.6 allows you to do:

$ svn up --accept=mine

Which is probably close to what he is asking.  The problem is that
option only applies when there are conflicts.  If you are previewing
an update and decide that you just want to keep your local version in
favor of the repository then this option would only have an impact if
svn could not update the local copy without conflicts.

-- 
Thanks

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

Re: pre-lock.bat Failed in Repo browser

[Michael Diers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-03-10 11:21, Michael Diers wrote:
> On 2011-03-10 08:23, Waseem Bokhari wrote:
>> This script works fine in all scenarios except Anyone can Steal Lock when 
>> Unlock.
> 
>>> Unable to Break lock through check for modifications Option
>>> Unable to break lock through Repo browser
>> BUT
>>  Only  any user can Steal Lock when he tried to Get Lock and Check 
>> the below mentioned Option of Steal Lock.
> 
> Waseem,
> 
> I'm not following. Could you please express the scenarios in terms of
> command line client operations? (Otherwise, dedicated TortoiseSVN forums
> might be a better place to ask for assistance.)
> 
> For instance, "Unable to break lock through Repo browser" translates to
> "Unable to break lock through `svn unlock --force'".

OK, there are two ways to get rid of locks owned by some other user:

"stealing a lock" by running `svn lock --force'

and

"breaking a lock" by running `svn unlock --force'.

If you want to hook these operations, you need a pre-lock hook script
and a a pre-unlock hook script, respectively. Note that in both cases,
the fact that the user specified "--force" is not communicated to the
hook script.

It appears you want to completely disallow "stealing" and "breaking" of
locks. So, for both hook scripts, if the calling user is not identical
to the lock owner, you want to fail the hook script.

Does that sound about right?

- -- 
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1+ldgACgkQcEKlWnqVgz0wlACffP0n70AJcqTcVunR2hlXp74V
TyoAn00a2XVgosKZvoug63/kBY2tX4KT
=mNfa
-END PGP SIGNATURE-

Re: pre-lock.bat Failed in Repo browser

[Daniel Becroft]

On Tue, Mar 15, 2011 at 8:25 AM, Michael Diers  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2011-03-10 11:21, Michael Diers wrote:
> > On 2011-03-10 08:23, Waseem Bokhari wrote:
> >> This script works fine in all scenarios except Anyone can Steal Lock
> when Unlock.
> >
> >>> Unable to Break lock through check for modifications Option
> >>> Unable to break lock through Repo browser
> >> BUT
> >>  Only  any user can Steal Lock when he tried to Get Lock and
> Check the below mentioned Option of Steal Lock.
> >
> > Waseem,
> >
> > I'm not following. Could you please express the scenarios in terms of
> > command line client operations? (Otherwise, dedicated TortoiseSVN forums
> > might be a better place to ask for assistance.)
> >
> > For instance, "Unable to break lock through Repo browser" translates to
> > "Unable to break lock through `svn unlock --force'".
>
> OK, there are two ways to get rid of locks owned by some other user:
>
> "stealing a lock" by running `svn lock --force'
>
> and
>
> "breaking a lock" by running `svn unlock --force'.
>
> If you want to hook these operations, you need a pre-lock hook script
> and a a pre-unlock hook script, respectively. Note that in both cases,
> the fact that the user specified "--force" is not communicated to the
> hook script.
>
> It appears you want to completely disallow "stealing" and "breaking" of
> locks. So, for both hook scripts, if the calling user is not identical
> to the lock owner, you want to fail the hook script.
>
> Does that sound about right?
>

In addition to this, locks are for a working-copy, not necessarily for a
user. It's possible for the same user to steal the lock that they already
hold in another working copy, and your script will let them.

Cheers,
Daniel B.

Re: Hosting multiple subdomains with a common SVNParentPath under apache

[Daniel Shahaf]

Ryan Schmidt wrote on Mon, Mar 14, 2011 at 15:34:10 -0500:
> 
> On Mar 14, 2011, at 11:15, Daniel Shahaf wrote:
> 
> >> You cannot use mod_rewrite or similar to fake this. Subversion clients do 
> >> not follow HTTP redirects.
> > 
> > They will in 1.7: 
> > http://subversion.apache.org/docs/release-notes/1.7#http-redirects
> 
> Neat! I see Subversion will in 1.7 follow permanent redirects but still error 
> on temporary redirects. What was the reason for not following temporary 
> redirects?
> 

I don't remember; try grepping the dev@ list for "302".

Here is the most recent (relevant) match:
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/125281

Require better support for Tags, Branches, and Merge operations in Subversion when using svn:externals

[D, Dinoj]

Hi, 

 

When using Subversion with a large project that integrates multiple
independent libraries and modules that come from different SVN
repositories, it is necessary to use the svn:external mechanism to link
to the different modules in subversion. However there are several
problems with using externals when active development is also going on
within the referenced module.

Summary:

1) References must be individually managed with "svn propedit"
2) References should be pinned to specific versions when tagging.
3) Tagging should result in a tag being created in the referenced
repository
4) Branching should result in a tag being created in the referenced
repository
5) Commits should be recursive
6) Merges should be recursive

Please help us to solve this at the earliest.

 

Thanks & Regards,

Dinoj D

Desk: +91 80 26588360 Extn: 48547

Cell: +91 9916668051