Re: Antwort: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Ryan Schmidt]

On Feb 22, 2011, at 01:27, Thomas STEININGER wrote:

> Ok - you mean that i start a script that iterates over all files and within 
> over all revisions of the repository 
> and execute on it your command. 

No, just iterate over all revisions. As you've said before and again below, 
you're not going to be modifying any of the files in your repository, just the 
log messages of each revision.

> But you say 'and converts that file (in-place) from latin1 to utf8' and i 
> have no problem with the file-contents itself. 
> The files have correct contents - including  mutated vowel. 

The file he's talking about here is a file that will (temporarily) contain the 
log message of each revision as the script runs.

> My Problem is in the logs. 
> The log-messages (commit-comments) have  mutated vowel  and if i try to show 
> the log-comments of some file with Tortoisesvn or Eclipse-subversive with 
> JavaHL-Connector 
> i have a error and see nothing. 
> 
> So i must correct the checkin-comments. 
> 
> How can i get this done? 
> 
> Or does i have misunderstood your trick?

Re: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Johan Corveleyn]

[ Please do not top-post on this list, i.e. put your reply inline or
below the thing you're replying to. Also, if possible, use plain-text
email. More below ... ]

On Tue, Feb 22, 2011 at 8:27 AM, Thomas STEININGER
 wrote:
> Daniel Shahaf 
> > Thomas STEININGER wrote on Tue, Feb 22, 2011 at 07:39:49 +0100:
> > > do i really understand, that i have to execute this:
> > > propedit --editor-cmd 'sed --flags'
> > > on a file? on all urls that are in my svn-repository?
> > > or how you mean?
> > >
> >
> > On all revisions.
> >
> > What you'll want is to write a script that takes a filename in argv[1]
> > and converts that file (in-place) from latin1 to utf8.  Then you can use
> > that file as --editor-cmd.
> >
> > Something like
> > % svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e 
> > "s/\\xfc/\\xc3\\xbc/g"'
> > might just do the trick.  (untested)
> >
> Ok - you mean that i start a script that iterates over all files and within 
> over all revisions of the repository
> and execute on it your command.
> But you say 'and converts that file (in-place) from latin1 to utf8' and i 
> have no problem with the file-contents itself.
> The files have correct contents - including  mutated vowel.
>
> My Problem is in the logs.
> The log-messages (commit-comments) have  mutated vowel  and if i try to show 
> the log-comments of some file with Tortoisesvn or Eclipse-subversive with 
> JavaHL-Connector
> i have a error and see nothing.
>
> So i must correct the checkin-comments.
>
> How can i get this done?
>
> Or does i have misunderstood your trick?

Yes, you've misunderstood :-).

The important thing to realize is that log message (aka
checkin-comments) are *revision properties*, which means they are
associated with *revisions* directly, not with the files touched by
that revision. As opposed to *versioned properties*, which are
meta-data associated with files (like svn:eol-style, svn:keywords,
svn:mime-type etc...), and those properties are themselves versioned
(i.e., they can change from one revision to the other). You can find
some more background about this in the svn book:

http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html

This means that you can change a revision property, like "svn:log"
(i.e. the checkin-comment), without specifying a file. Just a
revision, together with the --revprop option, should do the trick.
That is, if the change is allowed by the server, which means that the
"pre-revprop-change" hook should allow the change (by default it
doesn't). See this chapter for some more info about that:


http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.setlog

So, all that being said, what Daniel means is that you could apply
something like:

svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e
"s/\\xfc/\\xc3\\xbc/g"'

to all revisions (REV) that need to be corrected (either a list that
you make up manually, or something automated with "svn propget
--revprop" combined with "sed", or something similar ...).

HTH,
--
Johan

Re: A fix for issue 3471

[Stephen Butler]

On Feb 22, 2011, at 6:54 , Rick Varney wrote:

> Hello,
>  
> I am introducing Subversion into our development environment.  We are using a 
> lock-modify-unlock stategy for all of our files.  I do not claim this is the 
> best or most efficient way to use Subversion, but it best fits the mindset of 
> the developers at my particular site.  We have installsed Subversion 1.6.6.
>  
> We ran into the bug documented as issue 3471: "svn up touches file w/ lock & 
> svn:keywords property"
>  
> http://subversion.tigris.org/issues/show_bug.cgi?id=3471
>  
> This is an annoyance for us, as we are using make to do our builds.
>  
> I am new to the subversion community, though I have had my eye on it for a 
> long time.  Here are my questions:
>  
> 1.  Is there a way for me to find out if there is planned fix for this issue?

Hi Rick,
There's a roadmap page for larger features, 

  http://subversion.apache.org/roadmap.html

but for a bug like this, find the issue in the tracker and ask on the 
users' list (as you've done).

> 2.  If there is not a plan to fix this issue in an upcoming release, is there 
> a way I can find out if anyone else has submitted a fix?

The issue resolution would have been set to FIXED.  Or there would
have been discussions on the developer list.  So it looks like no one's
worked on the issue yet.

> 3.  If there there is no submitted fix, how would I go about submitting one 
> should I attempt a fix myself?

The community guide explains how to check out the source code,
read the key header files, hack the code, run the tests, join the 
developer list, and submit a patch.

  http://subversion.apache.org/docs/community-guide/ 

When you check out the Subversion source, see the INSTALL file
for the list of dependencies to install or build first.

> 4.  If I were to attempt a fix, I would likely not be able to spend a great 
> deal of time fully verifying it, given that this is outside of my usual job 
> responsibilities.  Is there a way to submit a fix that others could help 
> verify - assuming that there are benevolent souls in the community that do 
> this sort of thing?

There's already a client test mentioned in the issue.  That's usually 
the first step.

If you submit a patch, others will critique it and test it.

>  
> In short, please clue me in on the conventions of getting or making a fix to 
> a bug I care about.  I am fine if the answer is "Read The Fine Manual", but 
> do please point me right manuals.

It seems like you already have a clue.  The community guide has
the information you need.


Cheers,
Steve


PS:  Before you dive in, have you tried the "use-commit-times" option
in your Subversion client config file?

  
http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config


--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Re: A fix for issue 3471

[Stefan Sperling]

On Mon, Feb 21, 2011 at 09:54:12PM -0800, Rick Varney wrote:
> Hello,
> 
> I am introducing Subversion into our development environment.  We are using a 
> lock-modify-unlock stategy for all of our files.  I do not claim this is the 
> best or most efficient way to use Subversion, but it best fits the mindset of 
> the developers at my particular site.  We have installsed Subversion 1.6.6.
> 
> We ran into the bug documented as issue 3471: "svn up touches file w/ lock & 
> svn:keywords property"
> 
> http://subversion.tigris.org/issues/show_bug.cgi?id=3471
>  
> This is an annoyance for us, as we are using make to do our builds.
>  
> I am new to the subversion community, though I have had my eye on it for a 
> long 
> time.  Here are my questions:
>  
> 1.  Is there a way for me to find out if there is planned fix for this issue?

No, apart from asking here or on dev@.
You can never exactly know who is working on what in an open source
project because resources aren't being managed from a central point.

That said, I'm not aware of anybody having expressed interest in
working on this issue. But I don't know everything the community
is up to, either.

> 2.  If there is not a plan to fix this issue in an upcoming release, is there 
> a 
> way I can find out if anyone else has submitted a fix?

Related patches will usually be logged to the issue.
Unless a patch has been submitted without people realising that there's
an issue filed for the problem. So again, you can never be sure :)

Searching the archives is the most reliable source of information about
past contributions. The archive at http://svn.haxx.se/dev has a search box.

> 3.  If there there is no submitted fix, how would I go about submitting one 
> should I attempt a fix myself?

This should get you started:
http://subversion.apache.org/contributing.html

In particular note these two sections:
http://subversion.apache.org/docs/community-guide/general.html#code-to-read
http://subversion.apache.org/docs/community-guide/general.html#patches
I found those two very valuable when I started out contributing to Subversion.

> 4.  If I were to attempt a fix, I would likely not be able to spend a great 
> deal 
> of time fully verifying it, given that this is outside of my usual job 
> responsibilities.  Is there a way to submit a fix that others could help 
> verify 
> - assuming that there are benevolent souls in the community that do this sort 
> of 
> thing?

Yes, sure. We do encourage new contributors and try to help them
off the ground as much as possible. Sending a patch to dev@ will
usually trigger feedback right away. If it doesn't you can re-send
every couple of days letting people know that you haven't received any
feedback yet. We never ignore contributions on purpose. We have a patch
manager who takes care of contributions that have slipped through the
cracks in case submitters don't ping their own contributions:
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager

> In short, please clue me in on the conventions of getting or making a fix to 
> a 
> bug I care about.  I am fine if the answer is "Read The Fine Manual", but do 
> please point me right manuals.
>  
> Many thanks in advance!

Hope this helps!

Stefan

>  
> Best regards,
>  
> Rick Varney

Subversion 1.7

[Waseem Bokhari]

Hi Experts!
I have read out a lot for Subversion 1.7 ; Can
you guys share when does it release for us?
 
Thanks


DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely 
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email 
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar 
expressions, identify forward looking statements, but their absence does not 
mean that the 
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of 
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained 
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and 
assumptions that are difficult to predict. The company will not undertake to 
update any statements 
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses. 
Although the company has taken reasonable precautions to ensure no viruses are 
present in this 
email, the company does not accept responsibility for any loss or damage 
arising from the use of 
this email or attachment. Note: Please consider the environment before printing 
this e-mail. 

Re: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, Feb 22, 2011 at 09:43:25 +0100:
> So, all that being said, what Daniel means is that you could apply
> something like:
> 
> svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e
> "s/\\xfc/\\xc3\\xbc/g"'
> 
> to all revisions (REV) that need to be corrected (either a list that
> you make up manually, or something automated with "svn propget
> --revprop" combined with "sed", or something similar ...).

By the way, please don't consider this a generic solution.  It's
a *shortcut*, which is probably okay for ü, but WILL corrupt your log
messages if you adapt it for §.

Re: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, Feb 22, 2011 at 11:26:25 +0200:
> Johan Corveleyn wrote on Tue, Feb 22, 2011 at 09:43:25 +0100:
> > So, all that being said, what Daniel means is that you could apply
> > something like:
> > 
> > svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e
> > "s/\\xfc/\\xc3\\xbc/g"'
> > 
> > to all revisions (REV) that need to be corrected (either a list that
> > you make up manually, or something automated with "svn propget
> > --revprop" combined with "sed", or something similar ...).
> 
> By the way, please don't consider this a generic solution.  It's
> a *shortcut*, which is probably okay for ü, but WILL corrupt your log
> messages if you adapt it for §.

... because the latin1 byte sequence for § is part of some UTF-8
byte sequences.

(I'm assuming that at least some log messages are already in UTF-8.)

Subverion 1.7 Centralized Metadata Storage

[Nguyen Vu Hung (VNC)]

Hello all,

Could anyone please explain a little on the following feature?
Specifically, my questions are

* How it affects the current subversion (1.6) features and performance
* This way makes svn git-like :), my first impression is that:
  subversion will be distributed, not centralized :)

Centralized Metadata Storage

A key feature of the changes introduced in Subversion 1.7 is the 
centralization of worky copy metadata storage into a single location. 
Instead of a .svn directory in every directory in the working copy, 
Subversion 1.7 working copies have just one .svn directory—in the root 
of the working copy. This directory includes (among other things) an 
SQLite-backed database which contains all of the metadata Subversion 
needs for that working copy.


Even though the data is stored in a structured format, the relationships 
between the data are complex. We highly discourage external tools from 
modifying the data held in this database, as such modification is likely 
to result in working copy corruption.

Re: Subversion 1.7

[Ulrich Eckhardt]

On Tuesday 22 February 2011, Waseem Bokhari wrote:
> I have read out a lot for Subversion 1.7 ; Can
> you guys share when does it release for us?

Take a look at Subversion's roadmap.

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino 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. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Subverion 1.7 Centralized Metadata Storage

[Ulrich Eckhardt]

On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote:
> Could anyone please explain a little on the following feature?
> Specifically, my questions are
>
> * How it affects the current subversion (1.6) features and performance

Not at all.

> * This way makes svn git-like :), my first impression is that:
>subversion will be distributed, not centralized :)

SVN has one .svn directory in every (versioned) child directory of a working 
copy. This has the effect that every child directory of a working copy is 
itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a 
single place to store this. 

In any case, this has nothing to do with the way that "distributed" is used in 
the context of version control systems. This is not about distributed vs 
centralised repositories, but about WC metadata storage.

HTH

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino 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. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Subverion 1.7 Centralized Metadata Storage

[Thorsten Schöning]

Guten Tag Ulrich Eckhardt,
am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:

> SVN has one .svn directory in every (versioned) child directory of a working
> copy. This has the effect that every child directory of a working copy is
> itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> single place to store this. 

This won't be configurable, won't it? I always found it really
practical to be able to just copy/move entire sub folders of my
working copy to a new location and have a functional working copy,
without the need to checkout over and over again.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Eric Cordon/FR/EUROPE/GROUP is out of the office.

[eric . cordon]

Je serai absent(e) à partir du  02/19/2011 de retour le 02/27/2011.

I will be out of the office
I am off, picking up e-mails only occasionnally
For all important issues please reach directly:
For Synapse : Patrice Canchon
For OPTIME : Optime Dev Eu (Raphael Glaizaud- Chant Mouradian)
For Fibex : Fibex Dev EU (Damien Delvallée - Eric Michaux)
For Dolce project : Ludivine Police
For Hercule Project : Eric De la Tullaye
For Fortis EQD Brokerage intergation : Eric De la Tullaye
For all other important issues : Werner Kloberdanz




This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 
Do not print this message unless it is necessary,
consider the environment.

-

Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire,
pensez a l'environnement.

Re: Subverion 1.7 Centralized Metadata Storage

[Stefan Sperling]

On Tue, Feb 22, 2011 at 11:54:05AM +0100, Thorsten Schöning wrote:
> Guten Tag Ulrich Eckhardt,
> am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:
> 
> > SVN has one .svn directory in every (versioned) child directory of a working
> > copy. This has the effect that every child directory of a working copy is
> > itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> > single place to store this. 
> 
> This won't be configurable, won't it? I always found it really
> practical to be able to just copy/move entire sub folders of my
> working copy to a new location and have a functional working copy,
> without the need to checkout over and over again.

There will be a detach command to support this use case eventually.
So far it's not present in trunk so probably not in 1.7, but later.

In the meantime, you'll just have to live without this technically
unsupported use case which only worked because of a side-effect of
the 1.6 working copy design.

RE: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Tony Sweeney]

 

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: 22 February 2011 09:34
> To: Johan Corveleyn
> Cc: Thomas STEININGER; Stephen Connolly; users@subversion.apache.org
> Subject: Re: Re: Antwort: Re: problem with mutated vowel in 
> log-message-contents
> 
> Daniel Shahaf wrote on Tue, Feb 22, 2011 at 11:26:25 +0200:
> > Johan Corveleyn wrote on Tue, Feb 22, 2011 at 09:43:25 +0100:
> > > So, all that being said, what Daniel means is that you 
> could apply 
> > > something like:
> > > 
> > > svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e 
> > > "s/\\xfc/\\xc3\\xbc/g"'
> > > 
> > > to all revisions (REV) that need to be corrected (either 
> a list that 
> > > you make up manually, or something automated with "svn propget 
> > > --revprop" combined with "sed", or something similar ...).
> > 
> > By the way, please don't consider this a generic solution.  It's a 
> > *shortcut*, which is probably okay for ü, but WILL corrupt your log 
> > messages if you adapt it for §.
> 
> ... because the latin1 byte sequence for § is part of some 
> UTF-8 byte sequences.

Which is why you should probably use iconv(1) or any of the APIs listed here:

http://www.unicodetools.com/

instead of dicking around with perl or sed and hard coded hand crafted single 
character mappings.  There's potentially a lot more than just u-umlaut to worry 
about.

Tony.

> 
> (I'm assuming that at least some log messages are already in UTF-8.)
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: Subverion 1.7 Centralized Metadata Storage

[Waseem Bokhari]

If the structures are being changed then would there be any impact on
existing Working copies or structure in SVN? I am working on Windows
Environment ; please advice precautions and advices accordingly.

Regards
Waseem


-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Tuesday, February 22, 2011 4:44 PM
To: Thorsten Schöning
Cc: users@subversion.apache.org
Subject: Re: Subverion 1.7 Centralized Metadata Storage

On Tue, Feb 22, 2011 at 11:54:05AM +0100, Thorsten Schöning wrote:
> Guten Tag Ulrich Eckhardt,
> am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:
>
> > SVN has one .svn directory in every (versioned) child directory of a
working
> > copy. This has the effect that every child directory of a working copy
is
> > itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> > single place to store this.
>
> This won't be configurable, won't it? I always found it really
> practical to be able to just copy/move entire sub folders of my
> working copy to a new location and have a functional working copy,
> without the need to checkout over and over again.

There will be a detach command to support this use case eventually.
So far it's not present in trunk so probably not in 1.7, but later.

In the meantime, you'll just have to live without this technically
unsupported use case which only worked because of a side-effect of
the 1.6 working copy design.

DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar
expressions, identify forward looking statements, but their absence does not 
mean that the
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and
assumptions that are difficult to predict. The company will not undertake to 
update any statements
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses.
Although the company has taken reasonable precautions to ensure no viruses are 
present in this
email, the company does not accept responsibility for any loss or damage 
arising from the use of
this email or attachment. Note: Please consider the environment before printing 
this e-mail.

Re: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Daniel Shahaf]

Tony Sweeney wrote on Tue, Feb 22, 2011 at 11:52:09 -:
> Which is why you should probably use iconv(1) or any of the APIs listed here:
> 
> http://www.unicodetools.com/
> 

+1 to iconv.

In reality, the editor-cmd.sh script will check whether the log message
(which, again, will be argv[1]) is in UTF-8 already or not, and run it
through 'iconv -f latin1 -t utf-8' if not.

It won't be long, but it won't be a one-liner.

> instead of dicking around with perl or sed and hard coded hand crafted single 
> character mappings.  There's potentially a lot more than just u-umlaut to 
> worry about.

Thanks,

Daniel

Re: Subverion 1.7 Centralized Metadata Storage

[Stefan Sperling]

On Tue, Feb 22, 2011 at 04:55:48PM +0500, Waseem Bokhari wrote:
> If the structures are being changed then would there be any impact on
> existing Working copies or structure in SVN? I am working on Windows
> Environment ; please advice precautions and advices accordingly.

You can find advice in the release notes (which are still
work-in-progress because 1.7 hasn't been released yet):
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

Re: A fix for issue 3471

[Daniel Shahaf]

Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> In particular note these two sections:
> http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> http://subversion.apache.org/docs/community-guide/general.html#patches
> I found those two very valuable when I started out contributing to Subversion.
> 

To be fair, #code-to-read has a mile-long list of header files, and I'm
not sure that all of them are needed right away :)

Re: A fix for issue 3471

[Stefan Sperling]

On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> > In particular note these two sections:
> > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> > http://subversion.apache.org/docs/community-guide/general.html#patches
> > I found those two very valuable when I started out contributing to 
> > Subversion.
> > 
> 
> To be fair, #code-to-read has a mile-long list of header files, and I'm
> not sure that all of them are needed right away :)

I did in fact spend a couple of days reading through them all before
I started writing any code. It did help a lot.

Re: Betr.: RE: Hook help

[ankush chadha]

> 

> > I am trying to write a hook to prevent deletion of elements through a
> pre-commit hook.
> 
> 
> >>If you're not using the bindings you'd want svnlook, probably svnlook
> diff.
> 
> >>But, do you really want such a hook? If a user has permission to add
> stuff they should be allowed to also unwind any mistakes, providing it's
> not a tag or something.
> 
> 
> Max : What do you mean by bindings?
> And also svnlook seems to give info about already commited stuff.. 
> Svnlook changed gives me info abt previous commit... (unless I got 
> everything wrong .. :-) )
> 
> Yes, I want to have deletion control on atleast one repo.
 

> The pre-commit hook will get two input parameters. The first is the 
> repostiory 
>path, the second is the 
>
> transaciton ID.  
> You need to pass this to svnlook:  
> svnlook diff c:\somerepository --transaction sometransactionId 
> This will allow you to watch the commit that's begin executed.  
> Have a look at the manual: 
> http://svnbook.red-bean.com/nightly/en/index.htmlIn 
>this case you 
>need 
>http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnlook
> but
> if > you have not yet read the entire manual, you really should, it will save 
>you a lot of time and headaches!


A different approach to solve the problem of tracking deletes

What we do is during the post-commit event, we identify the operation. 

If the revision consists of a delete operation, we add buzz words  such as 
delete in the subject of the post-commit email. 


In this way, developers have freedom to delete trivial stuff and at the same 
time managers can track of deletes.

Ankush


  

Re: A fix for issue 3471

[Daniel Shahaf]

Stefan Sperling wrote on Tue, Feb 22, 2011 at 15:10:57 +0100:
> On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> > > In particular note these two sections:
> > > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> > > http://subversion.apache.org/docs/community-guide/general.html#patches
> > > I found those two very valuable when I started out contributing to 
> > > Subversion.
> > > 
> > 
> > To be fair, #code-to-read has a mile-long list of header files, and I'm
> > not sure that all of them are needed right away :)
> 
> I did in fact spend a couple of days reading through them all before
> I started writing any code. It did help a lot.

The doc comments, sure.  But the text sounds like it says "Read every
docstring in those files", which isn't a good idea... (and IMO isn't as
useful as reading the relevant notes/ files, where they exist)

bug in mixed-version detection + single-file externals

[Jason Sachs]

I'm having trouble with single-file externals, and I suspect this is a
bug in svn rather than in my setup.

The file externals work fine except for one thing: they cause svn to
see my checkout incorrectly as a mixed-revision checkout. If I do a
clean checkout, and type "svnversion", instead of seeing a single
number, I see {rev1}:{rev2} where {rev1} is the earliest version of
the file external, and {rev2} is the actual version of the working
copy. (This does not occur with directory externals.)

The problem is not just confined to svnversion: more seriously, this
is preventing us from doing a --reintegrate merge, since svn complains
that I have a mixed-revision working copy.

This problem occurs both in command-line svn and in TortoiseSVN.
I am using
svn, version 1.6.15 (r1038135)
compiled Nov 25 2010, 16:55:30

TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01

this is running on Windows XP

Is this a known bug? Is there a workaround other than not using file externals?

Re: A fix for issue 3471

[Johan Corveleyn]

On Tue, Feb 22, 2011 at 3:20 PM, Daniel Shahaf  wrote:
> Stefan Sperling wrote on Tue, Feb 22, 2011 at 15:10:57 +0100:
>> On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
>> > Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
>> > > In particular note these two sections:
>> > > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
>> > > http://subversion.apache.org/docs/community-guide/general.html#patches
>> > > I found those two very valuable when I started out contributing to 
>> > > Subversion.
>> > >
>> >
>> > To be fair, #code-to-read has a mile-long list of header files, and I'm
>> > not sure that all of them are needed right away :)
>>
>> I did in fact spend a couple of days reading through them all before
>> I started writing any code. It did help a lot.
>
> The doc comments, sure.  But the text sounds like it says "Read every
> docstring in those files", which isn't a good idea... (and IMO isn't as
> useful as reading the relevant notes/ files, where they exist)

I agree. That particular section was one of the major barriers for me
before getting started (well, apart from learning C, that is ;-)). I
almost gave up while stuck in read-mode ... Some people (like me) just
can't get any further before they have read and understood every
single line metioned there (and other files which are referred to from
the file being referred to, and so on ... until you've read half the
internet :-)). I admit I have punted on some of those ...

I think it would be better to get the big picture first, and then to
zoom in as quickly as possible to the area you're interested in, and
start experimenting. Trying to get your hands dirty as soon as
possible (diving into the code), while looking up stuff you don't
understand on a "need-to-understand" basis.

I think the community guide would benefit greatly from a refactoring
in this area, with the goal of lowering the barrier for potential
committers ... (though I admit I don't really have the time to have a
go at such a "refactoring" myself right now).

Cheers,
-- 
Johan

Re: bug in mixed-version detection + single-file externals

[Stefan Sperling]

On Tue, Feb 22, 2011 at 09:52:05AM -0500, Jason Sachs wrote:
> I'm having trouble with single-file externals, and I suspect this is a
> bug in svn rather than in my setup.
> 
> The file externals work fine except for one thing: they cause svn to
> see my checkout incorrectly as a mixed-revision checkout. If I do a
> clean checkout, and type "svnversion", instead of seeing a single
> number, I see {rev1}:{rev2} where {rev1} is the earliest version of
> the file external, and {rev2} is the actual version of the working
> copy. (This does not occur with directory externals.)
> 
> The problem is not just confined to svnversion: more seriously, this
> is preventing us from doing a --reintegrate merge, since svn complains
> that I have a mixed-revision working copy.

File externals are quite broken in 1.6.
Several known issues already exist:

  can't remove file externals
  http://subversion.tigris.org/issues/show_bug.cgi?id=3351

  Disallow modifications to file externals with specific revision
  http://subversion.tigris.org/issues/show_bug.cgi?id=3563

  file externals can break commits of WC->WC copies
  http://subversion.tigris.org/issues/show_bug.cgi?id=3589

The problem with reintegrate merges you are describing sounds
quite serious and should be added to the issue tracker.

Can you share more information to allow others to reproduce this problem?
What do your file externals definitions look like? Are you pinning externals
to known revisions or are they coming from URLS in the HEAD revision?

If you could write a script that starts with an empty repository, gets a
working copy, and runs svn commands until the problem triggers, that would
help greatly (and avoids any ambiguity in the problem description!).

> This problem occurs both in command-line svn and in TortoiseSVN.
> I am using
> svn, version 1.6.15 (r1038135)
> compiled Nov 25 2010, 16:55:30
> 
> TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01
> 
> this is running on Windows XP
> 
> Is this a known bug? Is there a workaround other than not using file 
> externals?

I hope that a workaround exists. Otherwise we might have to
add an option like --allow-mixed-revisions to svn merge in 1.6.x
(which already exists in trunk, a.k.a 1.7, for another reason)
in a 1.6.x patch release to allow people to work around this.

Errors in Building Perl Bindings

[Yudong Sun]

Hi,

I am trying to build the Perl bindings in subversion-1.6.2. The version 
is old because I want to add the Perl bindings to the existing svn 
installation.


I configure the subversion with the --with-swig=/path/to/swig option. 
Then I get a lot of errors during 'make check-swig-perl':


... ...
cd 
/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/native; 
make test
make[1]: Entering directory 
`/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/n

ative'
PERL_DL_NONLAZY=1 
LD_LIBRARY_PATH=/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/p

erl/libsvn_swig_perl/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_client/.libs:/w
ork/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_delta/.libs:/work/z03/z03/ydsun/queries/q149
281_git_svn/subversion-1.6.2/subversion/libsvn_fs/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subv
ersion/libsvn_ra/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_repos/.libs:/work/z
03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_wc/.libs:/work/z03/z03/ydsun/queries/q149281_git_
svn/subversion-1.6.2/subversion/libsvn_diff/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion
/libsvn_subr/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_ra_local/.libs:/work/z0
3/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_ra_svn/.libs:/work/z03/z03/ydsun/queries/q149281_g
it_svn/subversion-1.6.2/subversion/libsvn_ra_neon/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subv
ersion/libsvn_ra_serf/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_fs_base/.libs:
/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_fs_util/.libs:/work/z03/z03/ydsun/queries/
q149281_git_svn/subversion-1.6.2/subversion/libsvn_fs_fs/.libs 
/usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness
(0, 'blib/lib', 'blib/arch')" 
../../../../../subversion/bindings/swig/perl/native/t/*.t
../../../../../subversion/bindings/swig/perl/native/t/0use.NOK 
1/7

#   Failed test 'use SVN::Core;'
#   at ../../../../../subversion/bindings/swig/perl/native/t/0use.t line 5.
# Tried to use 'SVN::Core'.
# Error:  Can't load 
'/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/nati
ve/blib/arch/auto/SVN/_Core/_Core.so' for module SVN::_Core: 
libgfortran.so.3: cannot open shared object file: No such fi
le or directory at 
/usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203.
#  at 
/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/native/blib/lib/SVN/Base

.pm line 59
# BEGIN failed--compilation aborted at 
../../../../../subversion/bindings/swig/perl/native/t/0use.t line 5.

# Compilation failed in require at (eval 3) line 2.
# BEGIN failed--compilation aborted at (eval 3) line 2.
../../../../../subversion/bindings/swig/perl/native/t/0use.NOK 
2/7

#   Failed test 'use SVN::Repos;'
#   at ../../../../../subversion/bindings/swig/perl/native/t/0use.t line 6.
# Tried to use 'SVN::Repos'.
# Error:  Can't locate loadable object for module SVN::_Repos in 
@INC (@INC contains: /work/z03/z03/ydsun/queries/q14
9281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/native/blib/lib 
/work/z03/z03/ydsun/queries/q149281_git_svn/s
ubversion-1.6.2/subversion/bindings/swig/perl/native/blib/arch 
/usr/lib/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/p
erl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /us
r/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/
x86_64-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /
usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .
 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-threa
d-multi /usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi 
/usr/lib/perl5/vendor
_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bin

dings/swig/perl/native/blib/lib/SVN/Base.pm line 59
# BEGIN failed--compilation aborted at 
../../../../../subversion/bindings/swig/perl/native/t/0use.t line 6.

# Compilation failed in require at (eval 5) line 2.
# BEGIN failed--compilation aborted at (eval 5) line 2.
../../../../../subversion/bindings/swig/perl/native/t/0use.NOK 
3/7

#   Failed test 'use SVN::Fs;'
#   at ../../../../..

Re: Errors in Building Perl Bindings

[Stefan Sperling]

On Tue, Feb 22, 2011 at 03:23:04PM +, Yudong Sun wrote:
> I can fix the first libgfortran.so.3 not found error by adding the
> path to the LD_LIBRARY_PATH in
> ./subversion/bindings/swig/perl/native/Makefile.
> 
> What about the following 'Can't locate loadable object for module
> SVN::_Repos' etc? What are the loadable object needed?
> 
> Thanks,
> 
> Yudong

You probably need the path to the installed libsvn_* libraries in
LD_LIBRARY_PATH, too. See the bottom of this post:
http://svn.haxx.se/users/archive-2011-02/0300.shtml
What is said there about python bindings applies to the perl bindings
as well (and the ruby bindings, too).

SVN not updating original file

[Christopher D Haakinson]

Hi SVN mailing list! I'm a first timer with SVN and am having problems.

I followed this simple howto:

http://www.tonyspencer.com/2007/03/02/setup-a-subversion-server-in-4-minutes/

Now I have a repo setup that is accessible from remote clients. I can
checkout the repo files, edit any of the files included and commit these
changes back to SVN. To double-check I checked out the repo on a separate
machine and was able to see my changes made from the first workstation.

The problem I have is that the original file never changes, no matter how
many changes I make.

For example here's how my layout looks:

/svn/scripts<-- This folder has my original script files I want SVN to
track and update

"svn import /svn/scripts file:///svn/scripts"  is the command I run to
create the repo

/svn/scripts/check.sh  <-- this is the file I change on my remote client

So after I change this file, I commit the changes back to SVN and this
appears to work, however the file /svn/scripts/check.sh remains the same,
original un-edited file.

What am I doing wrong? Seems simple enough it just doesn't work. Thanks!

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

> The problem with reintegrate merges you are describing sounds
> quite serious and should be added to the issue tracker.

I had recently submitted it (but didn't know about posting to this list first).
See http://subversion.tigris.org/issues/show_bug.cgi?id=3816

> Can you share more information to allow others to reproduce this problem?
> What do your file externals definitions look like? Are you pinning externals
> to known revisions or are they coming from URLS in the HEAD revision?

They are pinned to known revisions, they look like "-r 12345
^/path/to/my/branch/somefile somefile"
(I never use the HEAD revision)


> If you could write a script that starts with an empty repository, gets a
> working copy, and runs svn commands until the problem triggers, that would
> help greatly (and avoids any ambiguity in the problem description!).

See attached python script (tested only on WinXP + Python 2.6.5)
import subprocess
import os

def getDirAsURL():
return "file:///"+(os.getcwd().replace('\\','/'))

def writeFile(filename,s):
with open(filename,"w") as f:
f.write(s)

def svnadd(path):
subprocess.call(["svn","add",path])

def svncommit(path,username,msg):
subprocess.call(["svn","commit",path,"--username",username,"-m",msg])

def svnpropset(path,propname,propval):
subprocess.call(["svn","propset",propname,propval,path])

def svnupdate(path):
subprocess.call(["svn","update",path])

def svnversion(path):
subprocess.call(["svnversion",path])

subprocess.call(["svnadmin","create","repos"])
subprocess.call(["svn","co",getDirAsURL()+"/repos","working"])
subprocess.call(["svn","mkdir","working/foo/trunk/","--parents"])
subprocess.call(["svn","mkdir","working/bar/trunk/","--parents"])
writeFile("working/foo/trunk/blah.txt","this is blah.txt, first version")
svnadd("working/foo/trunk/blah.txt")
svncommit("working","daemon","init checkin")
writeFile("working/foo/trunk/blah.txt","this is blah.txt, second version")
svncommit("working","daemon","next checkin")
writeFile("working/foo/trunk/blah.txt","this is blah.txt, third version")
svncommit("working","daemon","next checkin")
svnpropset("working/bar/trunk/","svn:externals"," blah.txt -r 1 
^/foo/trunk/blah.txt")
svncommit("working","daemon","add externals")
svnupdate("working")
svnversion("working")

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

>> If you could write a script that starts with an empty repository, gets a
>> working copy, and runs svn commands until the problem triggers, that would
>> help greatly (and avoids any ambiguity in the problem description!).
>
> See attached python script (tested only on WinXP + Python 2.6.5)
>

Script output:
=
C:\tmp\svn\ext1>python trybug.py
Checked out revision 0.
A C:\tmp\svn\ext1\working\foo
A C:\tmp\svn\ext1\working\foo\trunk
A C:\tmp\svn\ext1\working\bar
A C:\tmp\svn\ext1\working\bar\trunk
A working\foo\trunk\blah.txt
Adding working\bar
Adding working\bar\trunk
Adding working\foo
Adding working\foo\trunk
Adding working\foo\trunk\blah.txt
Transmitting file data .
Committed revision 1.
Sendingworking\foo\trunk\blah.txt
Transmitting file data .
Committed revision 2.
Sendingworking\foo\trunk\blah.txt
Transmitting file data .
Committed revision 3.
property 'svn:externals' set on 'working\bar\trunk'
Sendingworking\bar\trunk

Committed revision 4.

Fetching external item into 'working\bar\trunk\blah.txt'
Eworking\bar\trunk\blah.txt
Updated external to revision 1.

Updated to revision 4.
1:4

=
This just creates a sample repos + working copy and illustrates the
problem with svnversion, which should print out "4" but instead prints
out "1:4".

I didn't create a testcase for performing a merge, that's more complex
than I can deal with right now.

Re: SVN not updating original file

[Andy Levy]

On Tue, Feb 22, 2011 at 10:58, Christopher D Haakinson
 wrote:
> Hi SVN mailing list! I'm a first timer with SVN and am having problems.
>
> I followed this simple howto:
>
> http://www.tonyspencer.com/2007/03/02/setup-a-subversion-server-in-4-minutes/
>
> Now I have a repo setup that is accessible from remote clients. I can
> checkout the repo files, edit any of the files included and commit these
> changes back to SVN. To double-check I checked out the repo on a separate
> machine and was able to see my changes made from the first workstation.
>
> The problem I have is that the original file never changes, no matter how
> many changes I make.
>
> For example here's how my layout looks:
>
> /svn/scripts <-- This folder has my original script files I want SVN to
> track and update
>
> "svn import /svn/scripts file:///svn/scripts" is the command I run to create
> the repo
>
> /svn/scripts/check.sh <-- this is the file I change on my remote client
>
> So after I change this file, I commit the changes back to SVN and this
> appears to work, however the file /svn/scripts/check.sh remains the same,
> original un-edited file.
>
> What am I doing wrong? Seems simple enough it just doesn't work. Thanks!

What that tutorial fails to point out is that when you use svn import,
there is no connection made between the local directory and the
repository. All it does is push the contents of the local directory
into the repository.

This confusion can be mitigated by performing an "in-place import"
instead of a vanilla import. See
http://subversion.apache.org/faq.html#in-place-import

However, since you've already done the import, the safest route to go
now is to just check out a working copy from the repository.

Please also read the fine manual, http://svnbook.org/ . A "simple,
4-minute how-to" might *seem* OK for getting a repository set up, but
it really doesn't help you understand *how* Subversion works and how
to use it. In fact, that how-to completely glosses over *why* you're
running svnserve, and omits any discussion about administering it, and
I'm really puzzled as to why one would import via file:///, then fire
up svnserve, as opposed to just doing everything via svnserve (to
eliminate confusion).

Re: Errors in Building Perl Bindings

[Stefan Sperling]

On Tue, Feb 22, 2011 at 04:04:36PM +, Yudong Sun wrote:
> Stefan Sperling wrote, On 22/02/2011 15:47:
> >On Tue, Feb 22, 2011 at 03:23:04PM +, Yudong Sun wrote:
> >>I can fix the first libgfortran.so.3 not found error by adding the
> >>path to the LD_LIBRARY_PATH in
> >>./subversion/bindings/swig/perl/native/Makefile.
> >>
> >>What about the following 'Can't locate loadable object for module
> >>SVN::_Repos' etc? What are the loadable object needed?
> >>
> >>Thanks,
> >>
> >>Yudong
> >
> >You probably need the path to the installed libsvn_* libraries in
> >LD_LIBRARY_PATH, too. See the bottom of this post:
> >http://svn.haxx.se/users/archive-2011-02/0300.shtml
> >What is said there about python bindings applies to the perl bindings
> >as well (and the ruby bindings, too).
> >
> >
> >This e-mail has been scanned for all viruses by Star.
> >
> >
> 
> Hi Stefan,
> 
> I have included the subversion lib path
> '/work/z03/z03/ydsun/queries/q149281_git_svn/svn-1.6.2/lib' to the
> LD_LIBRARY_PATH (the last entry). However, the errors complain
> 'can't locate loadable object in @INC'. I can't figure out where
> @INC is set:


Try this:
  export PERL5LIB=/path/to/perl/libs

> 
> cd 
> /work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/native;
> make test
> make[1]: Entering directory 
> `/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/nati
> ve'
> PERL_DL_NONLAZY=1 
> LD_LIBRARY_PATH=/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/bindings/swig/perl
> /libsvn_swig_perl/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_client/.libs:/work/z0
> 3/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_delta/.libs:/work/z03/z03/ydsun/queries/q149281_git_s
> vn/subversion-1.6.2/subversion/libsvn_fs/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsv
> n_ra/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_repos/.libs:/work/z03/z03/ydsun/qu
> eries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_wc/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6
> .2/subversion/libsvn_diff/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_subr/.libs:/w
> ork/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_ra_local/.libs:/work/z03/z03/ydsun/queries/q149
> 281_git_svn/subversion-1.6.2/subversion/libsvn_ra_svn/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/sub
> version/libsvn_ra_neon/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_ra_serf/.libs:/w
> ork/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/subversion/libsvn_fs_base/.libs:/work/z03/z03/ydsun/queries/q1492
> 81_git_svn/subversion-1.6.2/subversion/libsvn_fs_util/.libs:/work/z03/z03/ydsun/queries/q149281_git_svn/subversion-1.6.2/sub
> version/libsvn_fs_fs/.libs:/opt/cray/mpt/5.1.2/xt/gemini/mpich2-gnu/lib:/opt/cray/pmi/1.0-1..8160.39.2.gem/lib64:/opt/gc
> c/mpc/0.8.1/lib:/opt/gcc/mpfr/2.4.2/lib:/opt/gcc/gmp/4.3.2/lib:/opt/gcc/4.5.1/snos/lib64:/opt/cray/xpmem/0.1-2.0301.24037.4.
> 2.gem/lib64:/opt/cray/dmapp/2.2-1.0301.2594.5.7.gem/lib64:/opt/cray/ugni/2.0-1.0301.2648.4.4.gem/lib64:/opt/cray/udreg/1.3-1
> .0301.2732.4.1.gem/lib64:/opt/cray/MySQL/5.0.64-1.0301.2899.20.2.gem/lib64/mysql:/opt/cray/MySQL/5.0.64-1.0301.2899.20.2.gem
> /lib64:/work/z03/z03/ydsun/queries/q149281_git_svn/svn-1.6.2/lib
> /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(
> 0, 'blib/lib', 'blib/arch')"
> ../../../../../subversion/bindings/swig/perl/native/t/*.t
> ../../../../../subversion/bindings/swig/perl/native/t/0use.NOK
> 2/7
> #   Failed test 'use SVN::Repos;'
> #   at ../../../../../subversion/bindings/swig/perl/native/t/0use.t line 6.
> # Tried to use 'SVN::Repos'.
> # Error:  Can't locate loadable object for module SVN::_Repos in
> @INC (@INC contains: /work/z03/z03/ydsun/queries/q14928
> 1_git_svn/subversion-1.6.2/subversion/bindings/swig/perl/native/blib/lib
> /work/z03/z03/ydsun/queries/q149281_git_svn/subvers
> ion-1.6.2/subversion/bindings/swig/perl/native/blib/arch
> /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10
> .0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0
> /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
> /usr/lib/perl5/
> site_perl/5.10.0/x86_64-linux-thread-multi
> /usr/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-th
> read-multi
> /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vend
> or_perl/5.10.0/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .
> /usr/lib/perl5/5.10.
> 0/x86

Re: bug in mixed-version detection + single-file externals

[Stefan Sperling]

On Tue, Feb 22, 2011 at 11:07:38AM -0500, Jason Sachs wrote:
> >> If you could write a script that starts with an empty repository, gets a
> >> working copy, and runs svn commands until the problem triggers, that would
> >> help greatly (and avoids any ambiguity in the problem description!).
> >
> > See attached python script (tested only on WinXP + Python 2.6.5)
> >
> 
> Script output:

[...]

> =
> This just creates a sample repos + working copy and illustrates the
> problem with svnversion, which should print out "4" but instead prints
> out "1:4".
> 
> I didn't create a testcase for performing a merge, that's more complex
> than I can deal with right now.

Thanks a lot. That's sufficient information to reproduce the problem.

I've put a link to this thread from the issue.
Thanks for reporting this.

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

Hmm, a merge attempt isn't that hard, here's another script that does
that, and has the same problem.

We don't use local file repositories, but this has the same symptom as
w/ a remote server.

hope it's either an easy fix or an easy workaround...

--Jason
import subprocess
import os

def getDirAsURL():
return "file:///"+(os.getcwd().replace('\\','/'))

def writeFile(filename,s):
with open(filename,"w") as f:
f.write(s)

def shellexec(a):
print(str(a))
subprocess.call(a)

def svnadd(path):
shellexec(["svn","add",path])

def svncommit(path,username,msg):
shellexec(["svn","commit",path,"--username",username,"-m",msg])

def svnpropset(path,propname,propval):
shellexec(["svn","propset",propname,propval,path])

def svnupdate(path):
shellexec(["svn","update",path])

def svnversion(path):
shellexec(["svnversion",path])

def svncopy(src,dest,username,msg):

shellexec(["svn","copy",src,dest,"--username",username,"-m",msg,"--parents"])

def svncheckout(src,dest):
shellexec(["svn","co",src,dest]);

def svnmkdir(path):
shellexec(["svn","mkdir",path,"--parents"])

def svnmerge_r(src,dest):
shellexec(["svn","merge","--reintegrate", src, dest])

user = "daemon"
shellexec(["svnadmin","create","repos"])
svncheckout(getDirAsURL()+"/repos","working")
svnmkdir("working/foo/trunk/")
svnmkdir("working/bar/trunk/")
svncommit("working",user,"init checkin")

svncheckout(getDirAsURL()+"/repos/foo/trunk","w_foo")
writeFile("w_foo/blah.txt","this is blah.txt, first version")
svnadd("w_foo/blah.txt")
svncommit("w_foo",user,"init checkin")
writeFile("w_foo/blah.txt","this is blah.txt, second version")
svncommit("w_foo",user,"next checkin")

svncheckout(getDirAsURL()+"/repos/bar/trunk","w_bar")
writeFile("w_bar/hohum.txt","hohum.txt")
svnadd("w_bar/hohum.txt")
svncommit("w_bar",user,"another checkin")
svncopy("w_bar",getDirAsURL()+"/repos/bar/branches/br1",user,"making a branch")

writeFile("w_foo/blah.txt","this is blah.txt, third version")
svncommit("w_foo",user,"next checkin")

svnupdate("w_bar")
svnpropset("w_bar","svn:externals"," blah.txt -r 3 ^/foo/trunk/blah.txt")
svncommit("w_bar",user,"add externals")

svnupdate("w_bar")
svnversion("w_bar")
svnmerge_r(getDirAsURL()+"/repos/bar/branches/br1","w_bar")

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

> hope it's either an easy fix or an easy workaround...

...or that it's something wrong with my setup and not a bug after all.

Re: bug in mixed-version detection + single-file externals

[Daniel Shahaf]

Jason Sachs wrote on Tue, Feb 22, 2011 at 11:07:38 -0500:
> >> If you could write a script that starts with an empty repository, gets a
> >> working copy, and runs svn commands until the problem triggers, that would
> >> help greatly (and avoids any ambiguity in the problem description!).
> >
> > See attached python script (tested only on WinXP + Python 2.6.5)
> >
> 
> Script output:
> =
> C:\tmp\svn\ext1>python trybug.py
> Checked out revision 0.
> A C:\tmp\svn\ext1\working\foo
> A C:\tmp\svn\ext1\working\foo\trunk
> A C:\tmp\svn\ext1\working\bar
> A C:\tmp\svn\ext1\working\bar\trunk
> A working\foo\trunk\blah.txt
> Adding working\bar
> Adding working\bar\trunk
> Adding working\foo
> Adding working\foo\trunk
> Adding working\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 1.
> Sendingworking\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 2.
> Sendingworking\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 3.
> property 'svn:externals' set on 'working\bar\trunk'
> Sendingworking\bar\trunk
> 
> Committed revision 4.
> 
> Fetching external item into 'working\bar\trunk\blah.txt'
> Eworking\bar\trunk\blah.txt
> Updated external to revision 1.
> 
> Updated to revision 4.
> 1:4
> 
> =
> This just creates a sample repos + working copy and illustrates the
> problem with svnversion, which should print out "4" but instead prints
> out "1:4".
> 
> I didn't create a testcase for performing a merge, that's more complex
> than I can deal with right now.

With a trunk build, I get a warning and the right svnversion output:

[[[
% python2.6 trybug.py
Checked out revision 0.
A /tmp/svn/working/foo
A /tmp/svn/working/foo/trunk
A /tmp/svn/working/bar
A /tmp/svn/working/bar/trunk
A working/foo/trunk/blah.txt
Adding working/bar
Adding working/bar/trunk
Adding working/foo
Adding working/foo/trunk
Adding working/foo/trunk/blah.txt
Transmitting file data .
Committed revision 1.
Sendingworking/foo/trunk/blah.txt
Transmitting file data .
Committed revision 2.
Sendingworking/foo/trunk/blah.txt
Transmitting file data .
Committed revision 3.
property 'svn:externals' set on 'working/bar/trunk'
Sendingworking/bar/trunk

Committed revision 4.
svn: Unrecognized format for the relative external URL 'blah.txt'.
4
]]]

I'm not sure what causes this, but for reference here's the output of
'svn help propset' from trunk:
[[[
...
svn:externals  - A newline separated list of module specifiers,
  each of which consists of a URL and a relative directory path,
  similar to the syntax of the 'svn checkout' command:
http://example.com/repos/zig foo/bar
  A revision to check out can optionally be specified to pin the
  external to a known revision:
-r25 http://example.com/repos/zig foo/bar
  To unambiguously identify an element at a path which has been
  deleted (possibly even deleted multiple times in its history),
  an optional peg revision can be appended to the URL:
-r25 http://example.com/repos/zig@42 foo/bar
  Relative URLs are indicated by starting the URL with one
  of the following strings:
../  to the parent directory of the extracted external
^/   to the repository root
//   to the scheme
/to the server root
  The ambiguous format 'relative_path relative_path' is taken as
  'relative_url relative_path' with peg revision support.
  Lines in externals definitions starting with the '#' character
  are considered comments and are ignored.
  Subversion 1.4 and earlier only support the following formats
  where peg revisions can only be specified using a -r modifier
  and where URLs cannot be relative:
foo http://example.com/repos/zig
foo/bar -r 1234 http://example.com/repos/zag
  Use of these formats is discouraged. They should only be used if
  interoperability with 1.4 clients is desired.
...
]]]

Re: bug in mixed-version detection + single-file externals

[Daniel Shahaf]

Jason Sachs wrote on Tue, Feb 22, 2011 at 11:36:45 -0500:
> Hmm, a merge attempt isn't that hard, here's another script that does
> that, and has the same problem.
> 
> We don't use local file repositories, but this has the same symptom as
> w/ a remote server.
> 
> hope it's either an easy fix or an easy workaround...
> 
> --Jason

> import subprocess
> import os
> 

Could you use "#!/usr/bin/env python" as the first line please?

Also, the script should rm -rf repos working w_foo w_bar, to make it
re-runnable.

> def getDirAsURL():
>   return "file:///"+(os.getcwd().replace('\\','/'))
> 
> def writeFile(filename,s):
>   with open(filename,"w") as f:
>   f.write(s)
>   
> def shellexec(a):
>   print(str(a))
>   subprocess.call(a)
>   
> def svnadd(path):
>   shellexec(["svn","add",path])
>   
> def svncommit(path,username,msg):
>   shellexec(["svn","commit",path,"--username",username,"-m",msg])
>   
> def svnpropset(path,propname,propval):
>   shellexec(["svn","propset",propname,propval,path])
>   
> def svnupdate(path):
>   shellexec(["svn","update",path])
>   
> def svnversion(path):
>   shellexec(["svnversion",path])
>   
> def svncopy(src,dest,username,msg):
>   
> shellexec(["svn","copy",src,dest,"--username",username,"-m",msg,"--parents"])
>   
> def svncheckout(src,dest):
>   shellexec(["svn","co",src,dest]);
> 
> def svnmkdir(path):
>   shellexec(["svn","mkdir",path,"--parents"])
>   
> def svnmerge_r(src,dest):
>   shellexec(["svn","merge","--reintegrate", src, dest])
>   
> user = "daemon"
> shellexec(["svnadmin","create","repos"])
> svncheckout(getDirAsURL()+"/repos","working")
> svnmkdir("working/foo/trunk/")
> svnmkdir("working/bar/trunk/")
> svncommit("working",user,"init checkin")
> 
> svncheckout(getDirAsURL()+"/repos/foo/trunk","w_foo")
> writeFile("w_foo/blah.txt","this is blah.txt, first version")
> svnadd("w_foo/blah.txt")
> svncommit("w_foo",user,"init checkin")
> writeFile("w_foo/blah.txt","this is blah.txt, second version")
> svncommit("w_foo",user,"next checkin")
> 
> svncheckout(getDirAsURL()+"/repos/bar/trunk","w_bar")
> writeFile("w_bar/hohum.txt","hohum.txt")
> svnadd("w_bar/hohum.txt")
> svncommit("w_bar",user,"another checkin")
> svncopy("w_bar",getDirAsURL()+"/repos/bar/branches/br1",user,"making a 
> branch")
> 
> writeFile("w_foo/blah.txt","this is blah.txt, third version")
> svncommit("w_foo",user,"next checkin")
> 
> svnupdate("w_bar")
> svnpropset("w_bar","svn:externals"," blah.txt -r 3 ^/foo/trunk/blah.txt")
> svncommit("w_bar",user,"add externals")
> 
> svnupdate("w_bar")
> svnversion("w_bar")
> svnmerge_r(getDirAsURL()+"/repos/bar/branches/br1","w_bar")


When I run this, the output ends with

[[[
Committed revision 7.
['svn', 'update', 'w_bar']
svn: Unrecognized format for the relative external URL 'blah.txt'.
['svnversion', 'w_bar']
7
['svn', 'merge', '--reintegrate', 'file:tmp/svn/repos/bar/branches/br1', 
'w_bar']
--- Merging differences between repository URLs into 'w_bar':
Aw_bar/hohum.txt
]]]

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

> svn: Unrecognized format for the relative external URL 'blah.txt'.
> 4
> ]]]
>
> I'm not sure what causes this, but for reference here's the output of
> 'svn help propset' from trunk:

 I had to use "blah.txt -r 3 ^/foo/trunk/blah.txt" rather than "-r 3
 ^/foo/trunk/blah.txt blah.txt" as it wouldn't work as a command-line
 argument. Perhaps someone can help me rewrite.

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

On Tue, Feb 22, 2011 at 11:50 AM, Daniel Shahaf  wrote:
> Could you use "#!/usr/bin/env python" as the first line please?
>
> Also, the script should rm -rf repos working w_foo w_bar, to make it
> re-runnable.
>

I can't seem to automatically delete the directoriesk (either by "rm
-rf" or python's shutil.rmtree()) due to repos\db\format having some
kind of lock. (Only way to delete on WinXP seems to be to remove the
directories via Windows Explorer)

I'm going to have to bow out at this point & get back to my real job

Re: SVN not updating original file

[Christopher D Haakinson]

I've read lots of tutorials on setting up and importing projects into SVN
and the majority of them use file:/// so maybe it's just a matter of choice
on how to import your project.

As for my issue, the solution is this:

Delete the contents of /svn/scripts  and then checkout a working copy from
SVN into the folder /svn/scripts

whala!! Now I have my files under version control and I can commit changes
directly!

Thanks for your input!!


|>
| From:  |
|>
  
>--|
  |Andy Levy   
 |
  
>--|
|>
| To:|
|>
  
>--|
  |Christopher D Haakinson/Raleigh/IBM@IBMUS
 |
  
>--|
|>
| Cc:|
|>
  
>--|
  |users@subversion.apache.org  
 |
  
>--|
|>
| Date:  |
|>
  
>--|
  |02/22/2011 11:14 AM  
 |
  
>--|
|>
| Subject:   |
|>
  
>--|
  |Re: SVN not updating original file   
 |
  
>--|





On Tue, Feb 22, 2011 at 10:58, Christopher D Haakinson
 wrote:
> Hi SVN mailing list! I'm a first timer with SVN and am having problems.
>
> I followed this simple howto:
>
>
http://www.tonyspencer.com/2007/03/02/setup-a-subversion-server-in-4-minutes/

>
> Now I have a repo setup that is accessible from remote clients. I can
> checkout the repo files, edit any of the files included and commit these
> changes back to SVN. To double-check I checked out the repo on a separate
> machine and was able to see my changes made from the first workstation.
>
> The problem I have is that the original file never changes, no matter how
> many changes I make.
>
> For example here's how my layout looks:
>
> /svn/scripts <-- This folder has my original script files I want SVN to
> track and update
>
> "svn import /svn/scripts file:///svn/scripts" is the command I run to
create
> the repo
>
> /svn/scripts/check.sh <-- this is the file I change on my remote client
>
> So after I change this file, I commit the changes back to SVN and this
> appears to work, however the file /svn/scripts/check.sh remains the same,
> original un-edited file.
>
> What am I doing wrong? Seems simple enough it just doesn't work. Thanks!

What that tutorial fails to point out is that when you use svn import,
there is no connection made between the local directory and the
repository. All it does is push the contents of the local directory
into the repository.

This confusion can be mitigated by performing an "in-place import"
instead of a vanilla import. See
http://subversion.apache.org/faq.html#in-place-import

However, since you've already done the import, the safest route to go
now is to just check out a working copy from the repository.

Please also read the fine manual, http://svnbook.org/ . A "simple,
4-minute how-to" might *seem* OK for getting a repository set up, but
it really doesn't help you understand *how* Subversion works and how
to use it. In fact, that how-to completely glosses over *why* you're
running svnserve, and omits any discussion about administering

Re: bug in mixed-version detection + single-file externals

[Daniel Shahaf]

Jason Sachs wrote on Tue, Feb 22, 2011 at 12:02:55 -0500:
> > svn: Unrecognized format for the relative external URL 'blah.txt'.
> > 4
> > ]]]
> >
> > I'm not sure what causes this, but for reference here's the output of
> > 'svn help propset' from trunk:
> 
>  I had to use "blah.txt -r 3 ^/foo/trunk/blah.txt" rather than "-r 3
>  ^/foo/trunk/blah.txt blah.txt" as it wouldn't work as a command-line
>  argument. Perhaps someone can help me rewrite.

Having fixed that (the fix was to use "--" in argv), I get this output
with your second script:

...
Fetching external item into 'w_bar/blah.txt'
svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a 
directory
['svnversion', 'w_bar']
7
['svn', 'merge', '--reintegrate', 'file:tmp/svn/repos/bar/branches/br1', 
'w_bar']
--- Merging differences between repository URLs into 'w_bar':
Aw_bar/hohum.txt
...

Re: bug in mixed-version detection + single-file externals

[Jason Sachs]

Shall we trade version info?

I'm running on WinXP SP3, with svn command line from Wandisco
binaries, svn version 1.6.15 (r1038135) compiled Nov 25 2010, 16:55:30

On Tue, Feb 22, 2011 at 2:09 PM, Daniel Shahaf  wrote:
> Having fixed that (the fix was to use "--" in argv), I get this output
> with your second script:
>
> ...
> Fetching external item into 'w_bar/blah.txt'
> svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a 
> directory
> ['svnversion', 'w_bar']
> 7
> ['svn', 'merge', '--reintegrate', 'file:tmp/svn/repos/bar/branches/br1', 
> 'w_bar']
> --- Merging differences between repository URLs into 'w_bar':
> A    w_bar/hohum.txt
> ...
>

Re: Behaviour on minor .control misconfiguration

[David Brodbeck]

On Sun, Feb 20, 2011 at 12:36 PM, Daniel creo Haslinger <
creo-23985-subvers...@blackmesa.at> wrote:

> I am not sure if it is proper behavior to ignore a whole file instead
> of a single misconfigured line.
>
> Of course there might be some reason to do this I'm not aware of,
> but I can't think of one yet :-)
>

The only problem I can see is it might result in more access than intended.
 e.g., what if the default is "*=rw", and I do "r=*" in an entry?  If it
just works, I might not realize right away that all users still have write
access.

On the other hand, in general the Subversion project maintainers' policy
seems to be to discourage use of path-based access control (see the box on
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html), so
it's possible you might get some people to agree that having the security
"fail open" is desirable here.

-- 
David Brodbeck
System Administrator, Linguistics
University of Washington

Re: bug in mixed-version detection + single-file externals

[Daniel Shahaf]

Recent trunk on Debian.

Jason Sachs wrote on Tue, Feb 22, 2011 at 16:04:24 -0500:
> Shall we trade version info?
> 
> I'm running on WinXP SP3, with svn command line from Wandisco
> binaries, svn version 1.6.15 (r1038135) compiled Nov 25 2010, 16:55:30
> 
> On Tue, Feb 22, 2011 at 2:09 PM, Daniel Shahaf  
> wrote:
> > Having fixed that (the fix was to use "--" in argv), I get this output
> > with your second script:
> >
> > ...
> > Fetching external item into 'w_bar/blah.txt'
> > svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a 
> > directory
> > ['svnversion', 'w_bar']
> > 7
> > ['svn', 'merge', '--reintegrate', 
> > 'file:tmp/svn/repos/bar/branches/br1', 'w_bar']
> > --- Merging differences between repository URLs into 'w_bar':
> > A    w_bar/hohum.txt
> > ...
> >

Re: A fix for issue 3471

[Rick Varney]

Many thanks for the replies on this.  I now feel fully clued in.
 
Best regards,
 
Rick