Re: Installing two subversion release on the same machine

[Emiliano . MONACO]

Hi,

sorry for the not so large explanation, anyway I defined PATH and 
LD_LIBRARY_PATH variable for my user as you suggested, anyway when I run 
svn checkout command:

svn checkout http://xxx.xxx.xxx.xxx/Doc_Folder  /tmp/tmp_doc

I got the following error:
subversion/libsvn_ra/ra_loader.c:470: (apr_err=17)
svn: Unrecognized URL scheme for 'http://xxx.xxx.xxx.xxx/Doc_Folder'

and with the command svn --version I got the following output:

svn, version 1.6.9 (r901367)
   compiled Mar 24 2010, 09:27:56

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet 
(http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network 
protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

So I immagine some module/library is missing in my build, and if it is 
like this, there is a way to add it into runtime build, or I hav to 
install again my svn?

Thanks,
Emiliano.






Ulrich Eckhardt  
03/24/2010 07:11 PM
Please respond to
users@subversion.apache.org


To
users@subversion.apache.org
cc

Subject
Re: Installing two subversion release on the same machine






On Wednesday 24 March 2010, emiliano.mon...@eu.steria.be wrote:
> I just installed new Subversion 1.6.9 and it seems to be working, anyway
> for some command it can not finde all the lib.

It might be important to actually say which lib and quote the exact error 
message.

> When you need to adjust my PATH and LD_LIBRARY_PATH are you meaning
> environment variable for my svn user???pointing to which location?

If you configure a prefix like e.g. "/home/uli/svn" then PATH needs to 
contain "/home/uli/svn/bin" and LD_LIBRARY_PATH needs "/home/uli/svn/lib".

Uli

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

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

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

Re: Installing two subversion release on the same machine

[Erik Andersson]

Maybe this will help?
http://subversion.apache.org/faq.html#unrecognized-url-error

Cheers / Erik

On Thu, Mar 25, 2010 at 8:56 AM,  wrote:

>
> Hi,
>
> sorry for the not so large explanation, anyway I defined PATH and
> LD_LIBRARY_PATH variable for my user as you suggested, anyway when I run
> svn checkout command:
>
> *svn checkout http://xxx.xxx.xxx.xxx/Doc_Folder  /tmp/tmp_doc*
>
> I got the following error:
> *subversion/libsvn_ra/ra_loader.c:470: (apr_err=17)*
> *svn: Unrecognized URL scheme for 'http://xxx.xxx.xxx.xxx/Doc_Folder'*
>
> and with the command* svn --version* I got the following output:
>
> *svn, version 1.6.9 (r901367)*
> *   compiled Mar 24 2010, 09:27:56*
>
> *Copyright (C) 2000-2009 CollabNet.*
> *Subversion is open source software, see http://subversion.tigris.org/*
> *This product includes software developed by CollabNet (
> http://www.Collab.Net/).*
>
> *The following repository access (RA) modules are available:*
>
> ** ra_svn : Module for accessing a repository using the svn network
> protocol.*
> *  - with Cyrus SASL authentication*
> *  - handles 'svn' scheme*
> ** ra_local : Module for accessing a repository on local disk.*
> *  - handles 'file' scheme*
>
> So I immagine some module/library is missing in my build, and if it is like
> this, there is a way to add it into runtime build, or I hav to install again
> my svn?
>
> Thanks,
> Emiliano.
>
>
>
>
>
>  *Ulrich Eckhardt *
>
> 03/24/2010 07:11 PM
>  Please respond to
> users@subversion.apache.org
>
>   To
> users@subversion.apache.org
> cc
>   Subject
> Re: Installing two subversion release on the same machine
>
>
>
>
> On Wednesday 24 March 2010, emiliano.mon...@eu.steria.be wrote:
> > I just installed new Subversion 1.6.9 and it seems to be working, anyway
> > for some command it can not finde all the lib.
>
> It might be important to actually say which lib and quote the exact error
> message.
>
> > When you need to adjust my PATH and LD_LIBRARY_PATH are you meaning
> > environment variable for my svn user???pointing to which location?
>
> If you configure a prefix like e.g. "/home/uli/svn" then PATH needs to
> contain "/home/uli/svn/bin" and LD_LIBRARY_PATH needs "/home/uli/svn/lib".
>
> Uli
>
> --
> ML: http://subversion.tigris.org/mailing-list-guidelines.html
> FAQ: http://subversion.tigris.org/faq.html
> Docs: http://svnbook.red-bean.com/
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
>
> **
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> **
>   Visit our website at 
>
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
> Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf
> weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
> werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie
> nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese
> Folgen nicht verantwortlich.
>
> **
>
>
>

weird merge

[Xavier Noria]

I am using 1.6 and was told that nowadays explicit revision numbers
are not needed for branching merging in the most common use case at
least.

That is, after you create branch b from trunk, you work on b,
occasionally you sync with trunk this way:

cd b
svn merge ^/trunk .

and when you are done in b finally

cd trunk
svn merge --reintegrate ^/branches/b .

First, that is correct right?

Alright, assuming it is, I've tried this in the project I am working on, and

svn merge ^/trunk .

instead of being silent says

--- Merging r2 through r2909 into '.'

and then a ton of tree conflicts appear. But that is kind of weird
because this project is at revision ~28000, why a range from 2 to
2909?

I am not into svn and do not know what to do. Can anyone guess what
could be happening?

merging repositories

[Tobias Pfeiffer]

Hi,

I have a project with two different repositories, named "Base" and 
"Develop" that I want to merge into one common repository. The simplest 
way would surely be to say:
 $ svnadmin dump Base/ base.dmp
 $ svnadmin dump Develop/ develop.dmp
 $ svnadmin load --parent-dir "Base/" Merged/ < base.dmp
 $ svnadmin load --parent-dir "Develop/" Merged/ < develop.dmp
However, this does not semantically respect the correct time order, e.g. 
files that have been developed in Develop/ and then later on moved to Base/ 
will appear earlier (= at a smaller revision number) in the merged repo 
than their origins.
(In addition, I don't really know what happens with the dates of commits. 
Will "svnadmin load" keep the commit dates and if so, what would be the 
outcome of, say, "svn update -r {someDate}"?)

There is a script out there that does what I want:
  http://www.cri.ensmp.fr/~coelho/svn-merge-repos.html
It does not much more than sort the commits from the input repositories by 
date, dump each revision using --incremental and then load it into the 
specified new repository. Now this becomes a problem when a commit (say, 
rev100) from repoA refers to some commit in the past of repoA (say, 
rev98).
 - With a normal "svnadmin load" (loading repoA:rev100 into repoC:rev500), 
this will work, as this command internally seems to say "don't use 
revision number 98, but the commit two revisions before", which isn't 98 
any more, but 498 now.
 - However, if there has been an incremental dump from repoB loaded into 
repoC in between, this will break, as "two commits before (in the old 
repository)" will not refer to the same commit as "two commits before (in 
the merged repository)" and - in my case - will refer to files that are not 
existing any more.
Did the problem get clear to you?

How can I work around this? It is not a hard task, I guess, to store a 
mapping "revision X from repoA means now revision Y in repoC" and compute 
the correct revision number of the merged repository that I have to refer 
to. But how can I make "svnadmin load" really *use* this newly computed 
revision number?

Thanks for your help,
Tobias


signature.asc
Description: This is a digitally signed message part.

RE: merging repositories

[Jon Foster]

Hi,

Tobias wrote:
> I have a project with two different repositories,
> that I want to merge into one common repository.

Would "svndumptool merge" do what you want?

http://svn.borg.ch/svndumptool/

(I haven't tried it, it's just something I found and
bookmarked when investigating Subversion)

> The simplest way would surely be to say:
>  $ svnadmin dump Base/ base.dmp
>  $ svnadmin dump Develop/ develop.dmp
>  $ svnadmin load --parent-dir "Base/" Merged/ < base.dmp
>  $ svnadmin load --parent-dir "Develop/" Merged/ < develop.dmp
> However, this does not semantically respect the correct time order
>[...]
> Will "svnadmin load" keep the commit dates

Yes.  They're just a revision property.

> and if so, what would be the outcome of, say,
> "svn update -r {someDate}"?)

Undefined (and unpredictable).  My understanding is that this
does a binary search, which will go haywire if your dates
aren't monotonically increasing.  So you can't use it on
such repositories.

Kind regards,

Jon

--
(Please direct all replies to the mailing list)


**
This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you 
must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re:

[David Weintraub]

Can you access the repository without IE 6 by doing a checkout and
commit? If so, it's pretty much working according to specs. Yes, it's
neat to be able to see your repository via IE and putting in the
checkout URL, but that's not a must have feature.

If you want to access your repository via IE, you should use a package
like Sventon (my favorite), ViewVC, or a commercial one like Fisheye.
Not only do they show you the current version, but they also show you
previous versions, the log, and diffs. They all work directly off the
repository using file:// protocol, so they bypass Apache. Sventon and
Fisheye can also use standard client acccess via svn://, svn+ssh://,
http://, and https://, so they don't have to be on your Subversion
repository server itself.

Other people on this list might be able to  point you to the exact
issue you're having, but if everything else is working, it probably is
not worth your time and effort to track it down.

I call it "tirage". Others calling it being a lazy goof. Either way,
when 5:00 comes around, I'm out of here.

On Wed, Mar 24, 2010 at 2:26 PM, Chong, Kim C.
 wrote:
> Hi,
>
> I am installing Apache and Subversion on Windows 2008 R2 and am having
> trouble making it to authenticate using Windows domain.
>
> When accessing the Subversion repository through IE 8, I am prompted for
> credential (which is expected), and after I entered the credential, I am
> getting the following error:
>
> Authorization Required
> This server could not verify that you are authorized to access the
> document requested. Either you supplied the wrong credentials (e.g., bad
> password), or your browser doesn't understand how to supply the
> credentials required.
>
> Additionally, a 404 Not Found error was encountered while trying to use an
> ErrorDocument to handle the request.
>
> I am wondering if it is caused by mod_auth.so module?  I couldn't find
> this module in the Apache Modules folder nor can I find it anyway on the
> internet.
>
> Can someone help or point me in the right direction?
>
> Thanks!
>
>
>
> Kim Chong
>
> Network Integrator
>
>



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

RE:

[Cooke, Mark]

> I am installing Apache and Subversion on Windows 2008 R2 and am having
> trouble making it to authenticate using Windows domain.
> 
> When accessing the Subversion repository through IE 8, I am 
> prompted for credential (which is expected), and after I
> entered the credential, I am getting the following error:
> 
> Authorization Required
> This server could not verify that you are authorized to access the
> document requested. Either you supplied the wrong credentials 
> (e.g., bad password), or your browser doesn't understand how to
> supply the credentials required.
> 
> Additionally, a 404 Not Found error was encountered while 
> trying to use an ErrorDocument to handle the request.
> 
I had a lot of trouble getting my apache config working for IE8 in a
windoze environment.  Have you tried using IE6 or a different browser.
I could login using e.g. Opera and IE6 but not IE8.  It turned out to be
an issue of IE8 trying to login using a windows form of single-sign-on
(this is the way I understand it but may not be factually accurate) that
meant that IE8 authentication always failed.

Using mod_sspi to do the authentication against active directory, the
magic settings ended up as:


Require valid-user

AuthType SSPI
AuthName ""
SSPIAuth On
SSPIAuthoritative On
SSPIDomain 
# OmitDomain _should_ strip the domain from the username for us
SSPIOmitDomain On

SSPIOfferSSPI Off
SSPIOfferBasic On
SSPIBasicPreferred On


...especially the last three lines.  These cause IE8 not to try to be
clever and use the basic route that actually works.  However, using
BASIC auth means you really need to use SSL as your username/password is
send in plain text across the network...

Now it is working I really like mod_auth_sspi but it is currently
without developers and the documentation is very lacking, a lot of
google time was required to get it working with IE8.  You should be able
to find it at http://mod-auth-sspi.sf.net/ but it seems to be
unavailable at the moment...

I hope this helps,

~ Mark C

RE: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Bob Archer]

> Subject: @ the turkey who compiled OSX svn 1.6 with hardcoded path of
> /opt/subversion...
> 
> ...please don't do that again.
> 
> is it asking too much to choose where to install it? or at least using
> something standard like /usr/local with soft links into /usr/local/bin?
> 
> my opinion of CollabNet has dropped way down.
> 

That's a bit harsh and perhaps a bit uncalled for knowing that pretty much most 
work done on svn is volunteered.

That said, you may want to try using MacPorts to install svn. I've never had a 
problem with it.

BOb

Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Andy Levy]

On Thu, Mar 25, 2010 at 10:11, Bob Archer  wrote:
>> Subject: @ the turkey who compiled OSX svn 1.6 with hardcoded path of
>> /opt/subversion...
>>
>> ...please don't do that again.
>>
>> is it asking too much to choose where to install it? or at least using
>> something standard like /usr/local with soft links into /usr/local/bin?
>>
>> my opinion of CollabNet has dropped way down.
>>
>
> That's a bit harsh and perhaps a bit uncalled for knowing that pretty much 
> most work done on svn is volunteered.

I think the CollabNet distribution is put together by people who are
on the CollabNet payroll.

RE: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Bob Archer]

> On Thu, Mar 25, 2010 at 10:11, Bob Archer  wrote:
> >> Subject: @ the turkey who compiled OSX svn 1.6 with hardcoded path of
> >> /opt/subversion...
> >>
> >> ...please don't do that again.
> >>
> >> is it asking too much to choose where to install it? or at least using
> >> something standard like /usr/local with soft links into /usr/local/bin?
> >>
> >> my opinion of CollabNet has dropped way down.
> >>
> >
> > That's a bit harsh and perhaps a bit uncalled for knowing that pretty
> much most work done on svn is volunteered.
> 
> I think the CollabNet distribution is put together by people who are
> on the CollabNet payroll.

Then it is collabnet that is volunteering their developers times. I still think 
this issue could have been brought up politely without name calling.

We're all in this together right?

BOb

Question regarding the python binding

[Tino Schwarze]

Hi there,

I'm currently implementing commit hooks and struggling with the python
bindings. I took the contributed pre-commit example which uses the "svn"
python module which maps more or less directly to libsvn functions.

Background: We want to enforce certain global ignores, MIME types etc.
The most coherent way should be to just read our default .svn/config
file and verify against it's settings. BTW: Has anybody done something
similar already?

Back to python: I managed to use the Python bindings to get a value from
the config file (I didn't want to reinvent the wheel) like this:

***
from svn import repos, fs, delta, core, client

def main(pool, repos_dir):

# for now, store client configuration in repository root
cfgfile = repos_dir+'/conf/client.conf'

svncfg = core.svn_config_read (cfgfile, True, pool)

global_ignores = core.svn_config_get (svncfg, 
core.SVN_CONFIG_SECTION_GLOBAL, core.SVN_CONFIG_OPTION_GLOBAL_IGNORES, None)

***

Now I'd like to verify our default set of required MIME types, so I need
to get the contents of the [auto-props] section from the config file.

libsvn provides the following function which should be suitable for my
needs:

svn_config_enumerate2(svn_config_t cfg, char section,
svn_config_enumerator2_t callback, void baton, apr_pool_t pool) -> int

Two questions arise:

1. How do I define an appropiate callback in Python? Looking at the SWIG
documentation, I see examples on how to implement Python callbacks but
they don't seem to match the current SVN bindings. I tried passing a
Python method, deriving from svn_config_enumerator2_t etc. -> Segfault.

2. What's the baton good for? Is it just some kind of additional data, I
don't need to care about?

Maybe the devel list is more appropiate for such questions, but I wanted
to try here first.

Thanks,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

Re: Question regarding the python binding

[Tino Schwarze]

Additional question: I can't seem to find an equivalent of "svnlook cat"
anywhere... I wanted to avoid calling external programs - commits are
slow enough already...

Thanks,

Tino.

On Thu, Mar 25, 2010 at 03:17:42PM +0100, Tino Schwarze wrote:
> Hi there,
> 
> I'm currently implementing commit hooks and struggling with the python
> bindings. I took the contributed pre-commit example which uses the "svn"
> python module which maps more or less directly to libsvn functions.
> 
> Background: We want to enforce certain global ignores, MIME types etc.
> The most coherent way should be to just read our default .svn/config
> file and verify against it's settings. BTW: Has anybody done something
> similar already?
> 
> Back to python: I managed to use the Python bindings to get a value from
> the config file (I didn't want to reinvent the wheel) like this:
> 
> ***
> from svn import repos, fs, delta, core, client
> 
> def main(pool, repos_dir):
> 
> # for now, store client configuration in repository root
> cfgfile = repos_dir+'/conf/client.conf'
> 
> svncfg = core.svn_config_read (cfgfile, True, pool)
> 
> global_ignores = core.svn_config_get (svncfg, 
> core.SVN_CONFIG_SECTION_GLOBAL, core.SVN_CONFIG_OPTION_GLOBAL_IGNORES, None)
> 
> ***
> 
> Now I'd like to verify our default set of required MIME types, so I need
> to get the contents of the [auto-props] section from the config file.
> 
> libsvn provides the following function which should be suitable for my
> needs:
> 
> svn_config_enumerate2(svn_config_t cfg, char section,
> svn_config_enumerator2_t callback, void baton, apr_pool_t pool) -> int
> 
> Two questions arise:
> 
> 1. How do I define an appropiate callback in Python? Looking at the SWIG
> documentation, I see examples on how to implement Python callbacks but
> they don't seem to match the current SVN bindings. I tried passing a
> Python method, deriving from svn_config_enumerator2_t etc. -> Segfault.
> 
> 2. What's the baton good for? Is it just some kind of additional data, I
> don't need to care about?
> 
> Maybe the devel list is more appropiate for such questions, but I wanted
> to try here first.
> 
> Thanks,
> 
> Tino.
> 
> -- 
> "What we nourish flourishes." - "Was wir nähren erblüht."
> 
> www.lichtkreis-chemnitz.de
> www.tisc.de

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de

Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Andy Levy]

On Thu, Mar 25, 2010 at 10:17, Bob Archer  wrote:
>> On Thu, Mar 25, 2010 at 10:11, Bob Archer  wrote:
>> >> Subject: @ the turkey who compiled OSX svn 1.6 with hardcoded path of
>> >> /opt/subversion...
>> >>
>> >> ...please don't do that again.
>> >>
>> >> is it asking too much to choose where to install it? or at least using
>> >> something standard like /usr/local with soft links into /usr/local/bin?
>> >>
>> >> my opinion of CollabNet has dropped way down.
>> >>
>> >
>> > That's a bit harsh and perhaps a bit uncalled for knowing that pretty
>> much most work done on svn is volunteered.
>>
>> I think the CollabNet distribution is put together by people who are
>> on the CollabNet payroll.
>
> Then it is collabnet that is volunteering their developers times. I still 
> think this issue could have been brought up politely without name calling.

Agreed on the name-calling.

I don't know that I'd call it volunteering their developers' time - I
mean, the company makes money off Subversion and Subversion-related
services among other things, in addition to contributing significant
resources to the development. I think it's great that they offer up
the binary packages for free; their Windows installer makes it easier
for me to get Subversion accepted in my organization.

Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Ryan Schmidt]

On Mar 24, 2010, at 20:56, Matt Harrison wrote:

> ...please don't do that again.
> 
> is it asking too much to choose where to install it? or at least using 
> something standard like /usr/local with soft links into /usr/local/bin?

I'm not familiar with other operating systems, but it's customary on Mac OS X 
for UNIX-type software to be compiled with hardcoded paths, which are thus not 
relocatable. I'm not sure what would need to be done to avoid that, I just know 
that's how things happen by default (and how all software in MacPorts is 
compiled, for example). If you want the software installed elsewhere, consider 
compiling it yourself. In some cases, you may be able to change the location 
after the fact with some extensive install_name_tool usage.

problem with peg revision

[Vincent Lefevre]

Hi,

It seems that peg revisions do not work when a directory has been
renamed. For instance:

$ svn info notes
Path: notes
Name: notes
URL: svn+ssh://mysvn/arith/stds-754/notes
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 35831
Node Kind: file
Schedule: normal
Last Changed Author: lefevre
Last Changed Rev: 19957
Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
Text Last Updated: 2010-01-04 19:18:16 +0100 (Mon, 04 Jan 2010)
Checksum: 06585f431d7af5737b91dcfacd4e7f6d

$ svn info -r19957 notes
Path: notes
Name: notes
URL: svn+ssh://mysvn/doc/fp/stds-754/notes
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 19957
Node Kind: file
Last Changed Author: lefevre
Last Changed Rev: 19957
Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)

$ svn info no...@19957
no...@19957:  (Not a valid URL)

svn: A problem occurred; see other errors for details
zsh: exit 1 svn info no...@19957

Is this a bug?

svn, version 1.6.9 (r901367)
   compiled Jan 27 2010, 08:12:30

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: weird merge

[Tyler Roscoe]

On Thu, Mar 25, 2010 at 11:09:49AM +0100, Xavier Noria wrote:
> That is, after you create branch b from trunk, you work on b,
> occasionally you sync with trunk this way:
> 
> cd b
> svn merge ^/trunk .
> 
> and when you are done in b finally
> 
> cd trunk
> svn merge --reintegrate ^/branches/b .
> 
> First, that is correct right?

Yes.

> svn merge ^/trunk .
> 
> instead of being silent says
> 
> --- Merging r2 through r2909 into '.'
> 
> and then a ton of tree conflicts appear. But that is kind of weird
> because this project is at revision ~28000, why a range from 2 to
> 2909?

For some reason, your branch doesn't know that it already has revisions
2 through 2909, so svn attempts to merge those revisions in, leading
(apparently) to tree conflicts.

You should look at your branch's ancestry to make sure those revisions
are not needed. If they're not, you can use a --record-only merge to
make the branch think it has those revisions. Subsequent merges from
trunk should then skip over those revisions and merge only what you
want.

hth,
tyler

Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Jeremy Whitlock]

> On Mar 24, 2010, at 20:56, Matt Harrison wrote:
>
>> ...please don't do that again.
>>
>> is it asking too much to choose where to install it? or at least using 
>> something standard like /usr/local with soft links into /usr/local/bin?
>

Well, that turkey is me.  There are actually a few things to discuss
here so we might as well go ahead and address each:

1) My Subversion builds are not custom.  They use Subversion build
scripts, untouched I might add, and the OS X tooling I use is also
untouched.  Any unsatisfactory result of this is not the cause of "the
turkey" but of the tooling.  I too have been biten by this or wanted
to change it so that hardcoded paths at least would be relative
instead of absolute but things are they way they are.  I'm not sure of
the problems they are causing you but if you would share, I'm sure I'm
competent enough to fix them.

2) The reason I chose /opt/subversion instead of the "standard"
locations is a simple one: There are many different ways to install
Subversion and I wanted to install somewhere that is not going to
interfere with other distributions.  A perfect example of this is
installing my binary and SCPlugin.  If I adhere to the /usr/local
"standard", both tools would have issues as they install their shared
libraries to the same place.  Being a Subversion committer, and not
just some CollabNet drone on the payroll, I also was trying to make it
so you could have my binary installed and it not interfere with the
Subversion development I was doing.  /opt is a standard location on
Unix platforms to install optional software, which Subversion is.

3) My work on maintaining the OS X binary is not a CollabNet thing.  I
don't get paid for it, I've gotten no kick backs/bonuses or anything
like that.  I started doing this when there was a need and to this day
it's still the most complete package you can find without using a
package manager.  Sure, I host it on CollabNet's site as a win-win for
them and me.  (The win for me is I don't have to worry about my web
hosting plan running out of bandwidth and the win for CollabNet is
they get some publicity from it.)  I am solely responsible for the
binary and CollabNet has no involvement in it other than the hosting
of the downloads.

4) My build process is in the open and finding the build script would
be easy had you read anything in the installer.  That being said,
being the only person involved with this and having no support/QA or
anything like that, it's more than possible that I could have a flaw
in my build process.  I've not see anything to that effect and neither
has anyone that's reached out to me.  (Yes, I've had to explain the
/opt vs. other standards a few times but in most cases, people
understand why when I explain it.)  The best part about this is I do
all of this IN THE OPEN.  Feel free to see the script at
http://svnbinaries.open.collab.net, again just like is mentioned in
the installer documentation.

Those things being said, if you'd like to contribute or make formal
requests about the binary, you now know I'm the guy to reach out to.
(Again, had you read anything in the installer you would had seen my
direct email and wouldn't of had to name call.)  Having problems with
the binary is one thing but the approach you took to voice your
complains were pretty childish.  It's people like you that make
generous people like myself question why they even bother.

-- 
Take care,

Jeremy Whitlock
http://www.thoughtspark.org

Re: Question regarding the python binding

[Роман Донченко]

Tino Schwarze  писал в своём письме Thu, 25 Mar  
2010 17:17:42 +0300:



Hi there,

Back to python: I managed to use the Python bindings to get a value from
the config file (I didn't want to reinvent the wheel) like this:

***
from svn import repos, fs, delta, core, client

def main(pool, repos_dir):

# for now, store client configuration in repository root
cfgfile = repos_dir+'/conf/client.conf'

svncfg = core.svn_config_read (cfgfile, True, pool)

global_ignores = core.svn_config_get (svncfg,  
core.SVN_CONFIG_SECTION_GLOBAL, core.SVN_CONFIG_OPTION_GLOBAL_IGNORES,  
None)


***

Now I'd like to verify our default set of required MIME types, so I need
to get the contents of the [auto-props] section from the config file.

libsvn provides the following function which should be suitable for my
needs:

svn_config_enumerate2(svn_config_t cfg, char section,
svn_config_enumerator2_t callback, void baton, apr_pool_t pool) -> int

Two questions arise:

1. How do I define an appropiate callback in Python? Looking at the SWIG
documentation, I see examples on how to implement Python callbacks but
they don't seem to match the current SVN bindings. I tried passing a
Python method, deriving from svn_config_enumerator2_t etc. -> Segfault.


I took a look, and unfortunately this callback is not supported. The  
reason for that is that SWIG can't automatically figure out how to call  
Python callbacks, so a chunk of boring code must be written for each  
callback type - and I guess no developers needed to scratch this  
particular itch.


If it was supported, however, the call would look like this (and it *will*  
look like this, after I become un-busy again and implement it):


def enumerator(name, value, pool):
  print "%s: %s" % (name, value)

core.svn_config_enumerate2(svncfg, core.SVN_CONFIG_SECTION_AUTO_PROPS,  
enumerator)



2. What's the baton good for? Is it just some kind of additional data, I
don't need to care about?


The baton argument is used up by the bindings themselves, you neither  
should nor can supply your own (this applies to all callbacks).



Maybe the devel list is more appropiate for such questions, but I wanted
to try here first.


Not really, since this is a use question. 8=]


Thanks,

Tino.


Roman.

Re: Question regarding the python binding

[Роман Донченко]

Tino Schwarze  писал в своём письме Thu, 25 Mar  
2010 17:32:35 +0300:



Additional question: I can't seem to find an equivalent of "svnlook cat"
anywhere... I wanted to avoid calling external programs - commits are
slow enough already...

Thanks,

Tino.


You basically need to apply repos.open, then repos.fs, then  
fs.revision_root, then fs.file_contents.


Roman.

Re: weird merge

[Xavier Noria]

On Thu, Mar 25, 2010 at 4:51 PM, Tyler Roscoe  wrote:

> You should look at your branch's ancestry to make sure those revisions
> are not needed. If they're not, you can use a --record-only merge to
> make the branch think it has those revisions. Subsequent merges from
> trunk should then skip over those revisions and merge only what you
> want.

I see.

Could you help with the command that is needed here? Never did that before.

Is there something we can do in trunk so that subsequent new branches
do not need to do the same?

ignore local change

[Ben Kim]

Dear list,

version: subversion 1.6.6 on cygwin, FC12 and also tortoise svn.



I have some local changes that I want to keep, and wish they did not show 
up in svn status.


For example,
on production
mail = "#users_real_email#"
on dev machine
mail = "#fake_email_for_debugging#"

I want subversion to ignore this difference when I do "svn status" 
locally.


< mail = "#users_real_email#"
---

mail = "#fake_email_for_debugging#"



But if there are other changes except for this, I want them to show upon
"svn status".

There is a need to change the file from time to time, so I don't want to 
put the whole file in svn:ignore list.



Is there a feature in subversion or subversion-perl that allows me to let
subversion "ignore" only certain differences within a file?




Thanks.

Ben Kim

RE: ignore local change

[Bob Archer]

> I have some local changes that I want to keep, and wish they did not show
> up in svn status.
> 
> For example,
> on production
>  mail = "#users_real_email#"
> on dev machine
>  mail = "#fake_email_for_debugging#"
> 
> I want subversion to ignore this difference when I do "svn status"
> locally.
> 
> < mail = "#users_real_email#"
> ---
> > mail = "#fake_email_for_debugging#"
> 
> 
> But if there are other changes except for this, I want them to show upon
> "svn status".
> 
> There is a need to change the file from time to time, so I don't want to
> put the whole file in svn:ignore list.
> 
> 
> Is there a feature in subversion or subversion-perl that allows me to let
> subversion "ignore" only certain differences within a file?

I think the most common way people do this is to create a template file and 
keep that in subversion. When a dev pulls down a working copy, they would copy 
the template file to the correct file name and edit it with their email address 
for example.

http://subversion.apache.org/faq.html#ignore-commit

BOb

Re: problem with peg revision

[David Weintraub]

I played around with svn info and pegged revisions, and had no
problems. Have you've looked at the svn log? That might be a place to
start and maybe help you understand when the name change took place.

One of the issues our users run into when specifying pegged revisions
is that they misstate the revision.

Let's say I removed directory "foo" and committed a new revision
10002. When you look at the svn log, you see that revision 10002 is
where I removed "foo".

Sometimes my developers will do something like this:

$ svn info f...@10002

and get the message that they used an invalid URL. I point out that in
this case, they need the revision BEFORE 10002:

$ svn info f...@10001

works.

Could there be something like that going on here?

On Thu, Mar 25, 2010 at 11:33 AM, Vincent Lefevre
 wrote:
> Hi,
>
> It seems that peg revisions do not work when a directory has been
> renamed. For instance:
>
> $ svn info notes
> Path: notes
> Name: notes
> URL: svn+ssh://mysvn/arith/stds-754/notes
> Repository Root: svn+ssh://mysvn
> Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
> Revision: 35831
> Node Kind: file
> Schedule: normal
> Last Changed Author: lefevre
> Last Changed Rev: 19957
> Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
> Text Last Updated: 2010-01-04 19:18:16 +0100 (Mon, 04 Jan 2010)
> Checksum: 06585f431d7af5737b91dcfacd4e7f6d
>
> $ svn info -r19957 notes
> Path: notes
> Name: notes
> URL: svn+ssh://mysvn/doc/fp/stds-754/notes
> Repository Root: svn+ssh://mysvn
> Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
> Revision: 19957
> Node Kind: file
> Last Changed Author: lefevre
> Last Changed Rev: 19957
> Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
>
> $ svn info no...@19957
> no...@19957:  (Not a valid URL)
>
> svn: A problem occurred; see other errors for details
> zsh: exit 1     svn info no...@19957
>
> Is this a bug?
>
> svn, version 1.6.9 (r901367)
>   compiled Jan 27 2010, 08:12:30
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
>



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

Re: ignore local change

[David Weintraub]

There's no way to do this easily:

Ignoring is only for non-subversion files. For example, if every time
I do a build, a directory called "build" is created, I can create an
ignore, so that this directory won't show up on "svn status', but if a
file is changed and is part of the Subversion repository, ignore won't
work.

What you can do is create a changelist and use that when you do
commands like svn status and svn diff. (BTW, I think you meant "svn
diff" in your original post. All "svn status" would do is list that
the file was modified).

Unfortunately, you have to keep manually maintaining your changelists
and remember to use the --cl parameter when you do things like "svn
status", "svn info", and of course, "svn commit".

Just as aside: I like the way Perforce handles changelists. In
Perforce you have the concept of a default changelist. All files that
are changed are placed in the default changelist unless you specify
otherwise. When you do any workspace command like a diff or commit,
and you don't specify a changelist, Perforce automatically operates
only on the default changelist.

That makes it easy to make a change in a file, and then toss it into
an "ignore" changelist. Doing a diff or status will ignore the
"ignore" changelist unless you specify otherwise in the workspace
command. And, most importantly, when you do a commit, and you don't
specify a changelist, only the files in your default changelist are
committed and not the ones in your "ignore" changelist.

The only issue is that developers sometimes forget about their
"ignore" changelist and never revert the changes or commit them. That
can allow a build to succeed on a developer's machine, but fail when
the build server attempts to do the build.


On Thu, Mar 25, 2010 at 12:54 PM, Ben Kim  wrote:
>
> Dear list,
>
> version: subversion 1.6.6 on cygwin, FC12 and also tortoise svn.
>
>
>
> I have some local changes that I want to keep, and wish they did not show up
> in svn status.
>
> For example,
> on production
>        mail = "#users_real_email#"
> on dev machine
>        mail = "#fake_email_for_debugging#"
>
> I want subversion to ignore this difference when I do "svn status" locally.
>
> < mail = "#users_real_email#"
> ---
>>
>> mail = "#fake_email_for_debugging#"
>
>
> But if there are other changes except for this, I want them to show upon
> "svn status".
>
> There is a need to change the file from time to time, so I don't want to put
> the whole file in svn:ignore list.
>
>
> Is there a feature in subversion or subversion-perl that allows me to let
> subversion "ignore" only certain differences within a file?
>
>
>
>
> Thanks.
>
> Ben Kim
>
>



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

RE: ignore local change

[Bob Archer]

BTW: TortoiseSVN does implement the "ignore change list" idea. Although, I 
would rather go with checking in a template and then using build scripts or 
deploy scripts to create the correctly named file populating and tokens in the 
file that need to be customized.

BOb



> There's no way to do this easily:
> 
> Ignoring is only for non-subversion files. For example, if every time
> I do a build, a directory called "build" is created, I can create an
> ignore, so that this directory won't show up on "svn status', but if a
> file is changed and is part of the Subversion repository, ignore won't
> work.
> 
> What you can do is create a changelist and use that when you do
> commands like svn status and svn diff. (BTW, I think you meant "svn
> diff" in your original post. All "svn status" would do is list that
> the file was modified).
> 
> Unfortunately, you have to keep manually maintaining your changelists
> and remember to use the --cl parameter when you do things like "svn
> status", "svn info", and of course, "svn commit".
> 
> Just as aside: I like the way Perforce handles changelists. In
> Perforce you have the concept of a default changelist. All files that
> are changed are placed in the default changelist unless you specify
> otherwise. When you do any workspace command like a diff or commit,
> and you don't specify a changelist, Perforce automatically operates
> only on the default changelist.
> 
> That makes it easy to make a change in a file, and then toss it into
> an "ignore" changelist. Doing a diff or status will ignore the
> "ignore" changelist unless you specify otherwise in the workspace
> command. And, most importantly, when you do a commit, and you don't
> specify a changelist, only the files in your default changelist are
> committed and not the ones in your "ignore" changelist.
> 
> The only issue is that developers sometimes forget about their
> "ignore" changelist and never revert the changes or commit them. That
> can allow a build to succeed on a developer's machine, but fail when
> the build server attempts to do the build.
> 
> 
> On Thu, Mar 25, 2010 at 12:54 PM, Ben Kim  wrote:
> >
> > Dear list,
> >
> > version: subversion 1.6.6 on cygwin, FC12 and also tortoise svn.
> >
> >
> >
> > I have some local changes that I want to keep, and wish they did not
> show up
> > in svn status.
> >
> > For example,
> > on production
> >        mail = "#users_real_email#"
> > on dev machine
> >        mail = "#fake_email_for_debugging#"
> >
> > I want subversion to ignore this difference when I do "svn status"
> locally.
> >
> > < mail = "#users_real_email#"
> > ---
> >>
> >> mail = "#fake_email_for_debugging#"
> >
> >
> > But if there are other changes except for this, I want them to show upon
> > "svn status".
> >
> > There is a need to change the file from time to time, so I don't want to
> put
> > the whole file in svn:ignore list.
> >
> >
> > Is there a feature in subversion or subversion-perl that allows me to
> let
> > subversion "ignore" only certain differences within a file?
> >
> >
> >
> >
> > Thanks.
> >
> > Ben Kim
> >
> >
> 
> 
> 
> --
> David Weintraub
> qazw...@gmail.com

svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)

[Gary M. Gere]

-All,

This is my first time posting to this alias; I apologize in advance for 
any protocol mistakes, but we are in a serious situation and I need to 
get some guidance/help as soon as possible.


I tried searching through the issues database but could not find 
anything that appeared to be the issue we are encountering, so I am 
posting this request.


We recently upgraded our subversion server software and are having major 
problems with merging after moving the subversion server from 1.4.2 to 
1.6.6. I am asking the user community for any help they can give us.


The details of the prior and current software versions are detailed at 
the end of this email.


The problem we are having is with 'svn merge' with a workspace that was 
checked out using the subversion 1.4.2 server:


  - cd 
  - svn merge -r revision1:revision2 SOURCE_SVN_URL .

This results in many unrelated files are having their properties change, 
and many unrelated files being included in the merge. It makes it very 
difficult to verify that the merge was successful when many unrelated 
files are included.


A small example:

An attempt to merge one change from sw1.0 to sw2.0 branch.
A folder called Docs contains files that have not been changed.
An svn diff produces the following:

   % cd /data/source/branches/sw2.0
   % svn stat -q Docs/
 M  Docs/WDS-RIS-Blueprint.odt
 M  Docs/WDS-RIS-Script-Usage.odt

   % svn diff Docs/

   Property changes on: Docs/WDS-RIS-Blueprint.odt
   ___
   Deleted: svn:mergeinfo


   Property changes on: Docs/WDS-RIS-Script-Usage.odt
   ___
   Deleted: svn:mergeinfo

A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6 
based clients. Those have not changed, and this behavior occurs even 
using a 1.6.9 client.


Can anyone provide any guidance, clues, pointers, etc. to what we need 
to do to address this issue??


Thank you very much in advance,
-GmG

Prior to last Monday 22-Mar-2010, we had a system running the following:
  - RHEL-5.3 64-bit (Linux 2.6.18-128.1.6.el5 #1 SMP Tue Mar 24 
12:05:57 EDT 2009 x86_64)
  - subversion 1.4.2 (r22196, Sep 1 2008) (subversion-1.4.2-4.el5, 
subversion-devel-1.4.2-4.el5, subversion-javahl-1.4.2-4.el5, 
subversion-perl-1.4.2-4.el5, subversion-ruby-1.4.2-4.el5)
  - openssl OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 
(mod_ssl-2.2.3-22.el5, openssl097a-0.9.7a-9.el5_2.1, 
openssl-0.9.8e-7.el5, openssl-devel-0.9.8e-7.el5)
  - httpd Apache/2.2.3 (Nov 12 2008) (httpd-2.2.3-22.el5, 
httpd-devel-2.2.3-22.el5, system-config-httpd-1.3.3.3-1.el5)

  - Berkeley DB 4.3.29 (db4-4.3.29-9.fc6, db4-devel-4.3.29-9.fc6)

The subversion repository is format "3"

We upgraded the system to:
  - RHEL-5.4 64-bit (Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 04:15:13 EDT 
2009 x86_64)
  - subversion 1.6.6 (r40053, Oct 22 2009) 
(subversion-1.6.6-0.1.el5.rf, subversion-devel-1.6.6-0.1.el5.rf, 
subversion-perl-1.6.6-0.1.el5.rf)
  - openssl OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 
(Mod_ssl-2.2.3-31.0.1.el5, openssl-0.9.8e-12.el5_4.1, 
openssl-devel-0.9.8e-12.el5_4.1, openssl-perl-0.9.8e-12.el5_4.1)
  - httpd Apache/2.2.3 (Sep 3 2009) (httpd-2.2.3-31.0.1.el5, 
httpd-manual-2.2.3-31.0.1.el5, system-config-httpd-1.3.3.1-1.el5.0.1)

  - Berkeley DB 4.3.29 (db4-4.3.29-10.el5, db4-devel-4.3.29-10.el5)

The subversion repository was not upgraded and is still in format "3".

RE: svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)

[Bob Archer]

> We recently upgraded our subversion server software and are having major
> problems with merging after moving the subversion server from 1.4.2 to
> 1.6.6. I am asking the user community for any help they can give us.
> 
> The details of the prior and current software versions are detailed at the
> end of this email.
> 
> The problem we are having is with 'svn merge' with a workspace that was
> checked out using the subversion 1.4.2 server:

Eww... not sure how great an idea it is to use a pre 1.5 server with 1.5 and 
1.6 clients. Although I'm not 100% sure of the ramifications... it could just 
be a performance issue and the client has to do more work to walk the tree of 
mergeinfo properties. Perhaps someone that knows a bit more about that issue 
will chime in here.

> 
>   - cd 
>   - svn merge -r revision1:revision2 SOURCE_SVN_URL .
> 
> This results in many unrelated files are having their properties change,
> and many unrelated files being included in the merge. It makes it very
> difficult to verify that the merge was successful when many unrelated
> files are included.
> 
> A small example:
> 
> An attempt to merge one change from sw1.0 to sw2.0 branch.
> A folder called Docs contains files that have not been changed.
> An svn diff produces the following:
> % cd /data/source/branches/sw2.0
> % svn stat -q Docs/
>  M  Docs/WDS-RIS-Blueprint.odt
>  M  Docs/WDS-RIS-Script-Usage.odt
> 

As you know a " M" (Space in first col M in second column) indicates that the 
properties where changed but not the file itself.


> % svn diff Docs/
> 
> Property changes on: Docs/WDS-RIS-Blueprint.odt
> ___
> Deleted: svn:mergeinfo
> 
> 
> Property changes on: Docs/WDS-RIS-Script-Usage.odt
> ___
> Deleted: svn:mergeinfo

This shows that you do have mergeinfo on your files. So, at some time someone 
did a merge probably at the Docs level or directly to a file which added the 
mergeinfo. Now you are doing it at a higher folder level so the data is being 
elided. There's not really anything wrong here.

You  might want to train your devs to always do merges at the same folder level 
to prevent all the merge data on child folders and files. If they weren't there 
then they wouldn't be elided.


> A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6
> based clients. Those have not changed, and this behavior occurs even using
> a 1.6.9 client.

I assume it doesn't happen when you use a 1.4 client... since this version 
doesn't include the merge tracking functionality.


> Can anyone provide any guidance, clues, pointers, etc. to what we need to
> do to address this issue??

I think there is nothing you can do to address it. But, to solve your problem 
you may just want to pipe the output to grep (or something) and ignore files 
with a status of " M" 

You might also want to upgrade your server... 1.4.x is pretty old and not 
supported with updates. 

I hope this helps.. sorry AFAIK there is no magic answer to make this easier. 

BOb

Re: svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)

[Gary M. Gere]

-Hi Bob,

First off, thank you very much for your quick reply.

We were running a 1.4.2 subversion server, and upgraded the subversion 
server to 1.6.6. The clients have not changed in any way, and were a mix 
of 1.4, 1.5 and 1.6 clients that used "http" only to communicate with 
the subversion server. We have not had any compatibility issues of any 
kind until we upgraded the server to 1.6.6.


The merge problem did not show up when the server was 1.4.2, but is now 
showing up with the 1.6.6 server.


We did not upgrade the database repository - it is still at version "3". 
I read somewhere in the 1.5 release notes that the "merge tracking" 
added to 1.5 will not be enabled unless the repository is upgraded, 
which it has not.


If I understand your reply correctly, what's happening is old 
svn:mergeinfo data that is no longer needed is being removed (property 
change only). Even though a large number of files are listed in the 
merge/commit, besides files that really were merged, the rest are just 
property changes.


Thank you very much.

-GmG


On 03/25/10 12:04, Bob Archer wrote:

We recently upgraded our subversion server software and are having major
problems with merging after moving the subversion server from 1.4.2 to
1.6.6. I am asking the user community for any help they can give us.

The details of the prior and current software versions are detailed at the
end of this email.

The problem we are having is with 'svn merge' with a workspace that was
checked out using the subversion 1.4.2 server:
 

Eww... not sure how great an idea it is to use a pre 1.5 server with 1.5 and 
1.6 clients. Although I'm not 100% sure of the ramifications... it could just 
be a performance issue and the client has to do more work to walk the tree of 
mergeinfo properties. Perhaps someone that knows a bit more about that issue 
will chime in here.

   

   - cd
   - svn merge -r revision1:revision2 SOURCE_SVN_URL .

This results in many unrelated files are having their properties change,
and many unrelated files being included in the merge. It makes it very
difficult to verify that the merge was successful when many unrelated
files are included.

A small example:

An attempt to merge one change from sw1.0 to sw2.0 branch.
A folder called Docs contains files that have not been changed.
An svn diff produces the following:
% cd /data/source/branches/sw2.0
% svn stat -q Docs/
  M  Docs/WDS-RIS-Blueprint.odt
  M  Docs/WDS-RIS-Script-Usage.odt

 

As you know a " M" (Space in first col M in second column) indicates that the 
properties where changed but not the file itself.


   

% svn diff Docs/

Property changes on: Docs/WDS-RIS-Blueprint.odt
___
Deleted: svn:mergeinfo


Property changes on: Docs/WDS-RIS-Script-Usage.odt
___
Deleted: svn:mergeinfo
 

This shows that you do have mergeinfo on your files. So, at some time someone 
did a merge probably at the Docs level or directly to a file which added the 
mergeinfo. Now you are doing it at a higher folder level so the data is being 
elided. There's not really anything wrong here.

You  might want to train your devs to always do merges at the same folder level 
to prevent all the merge data on child folders and files. If they weren't there 
then they wouldn't be elided.


   

A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6
based clients. Those have not changed, and this behavior occurs even using
a 1.6.9 client.
 

I assume it doesn't happen when you use a 1.4 client... since this version 
doesn't include the merge tracking functionality.


   

Can anyone provide any guidance, clues, pointers, etc. to what we need to
do to address this issue??
 

I think there is nothing you can do to address it. But, to solve your problem you may 
just want to pipe the output to grep (or something) and ignore files with a status of 
" M"

You might also want to upgrade your server... 1.4.x is pretty old and not 
supported with updates.

I hope this helps.. sorry AFAIK there is no magic answer to make this easier.

BOb
   

RE: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Curley, John]

This may not be the right forum and I apologize for that, but here goes.

1st, thank you Jeremy!

2nd, from a sysadmin perspective, I appreciate that the installation
process doesn't presume to know where everything goes. Having one
complete install structure has several advantage, like seeing how big it
is. I simply created links to the binaries in
/opt/CollabNet_Subversion/bin, in my preferred binary path, /usr/bin/. 

3rd, If your OS uses something like rpm, (Linux RH4 in my case), I used
the --relocate function to put the binaries in /usr/bin (on my desktop).

Cheers!
John

Re: @ the turkey who compiled OSX svn 1.6 with hardcoded path of /opt/subversion...

[Jeremy Whitlock]

> 1st, thank you Jeremy!

No problem.  Out of the thousands of people that download the binary,
to have only a handful of complaints isn't bad.  ;)

> 2nd, from a sysadmin perspective, I appreciate that the installation
> process doesn't presume to know where everything goes. Having one
> complete install structure has several advantage, like seeing how big it
> is. I simply created links to the binaries in
> /opt/CollabNet_Subversion/bin, in my preferred binary path, /usr/bin/.

I agree.  When I first shipped the binary I used /usr/local but for me
to maintain an uninstallation script was a nightmare because of all of
the files in /usr/local that might not be related to my binary, like
the dependencies and such.  I think there are many benefits to having
the binary in a single, isolated location instead of being co-mingled
with other softwares.  In the end, I stand behind my reasoning.  To
each his/her own I guess.

> 3rd, If your OS uses something like rpm, (Linux RH4 in my case), I used
> the --relocate function to put the binaries in /usr/bin (on my desktop).

I thought about that as well, having the installer allow you to choose
where to install and having a script ran during the installation that
would relocate.  I already have the script done, since it's part of my
build process.  I just have never had anyone ask for such a thing.
Most times, I explain my reasoning and people agree, or at least they
don't bring it up again.

Thanks for the feedback.

-- 
Take care,

Jeremy Whitlock
http://www.thoughtspark.org

Could not resolve path ... for history error

[Thomas O'Brien]

Hi all,

I recently ran into a problem retrieving revision information. The errors
for retrieving revision
history (using svn blame) happened after a recent move of a directory
containing Java
files. After the move I started to receive errors when using 'svn blame' so
I tried to do a
reverse merge. When using 'svn blame' continued to have errors I tried using
svn delete to
remove the directory and svn copy with the revision number before the
directory move to
restore the directory to the revision before the move. Now when I try to use
svn blame I am
receiving "Could not resolve path ... for history".

The exact line I am using is:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


which returned:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history

Running the command:
svn cat
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


returned the file as it existed before the directory move.

I have tried searching the web and the mailing list for users with a similar
problem but have
found none. From the "Version Control with Subversion" section on
resurrecting deleted items
using 'svn delete' on the directory then 'svn copy' on the revision before
the change should link
the new directory and files with the ones before the move and remove this
error but it did not.

Is there a way to restore my directory so the revision history of the files
are linked with the originals?



The full set of changes were as follows:
For reference:
Project: http://code.google.com/p/power-architect/
svn: version 1.6.3
Eclipse: version 3.4.1
Subclipse: version 1.6.3

Before any changes I was on r3393.

I started with moving the directory and all subdirectories and files at
trunk/src/ca to
trunk/src/main/java/ca using Eclipse and Subclipse.
The log:
svn log -v -r 3394 http://power-architect.googlecode.com/svn/trunk/

returned:
r3394 | thomasobrie...@gmail.com | 2010-03-24 17:07:56 -0400 (Wed, 24 Mar
2010) | 3 lines
Changed paths:
...
   D /trunk/src/ca
...
   A /trunk/src/main
   A /trunk/src/main/java
   A /trunk/src/main/java/ca (from /trunk/src/ca:3393)
...
This appears that the folder was moved correctly and the history of
/trunk/src/main/java/ca
is linked to /trunk/src/ca as expected.

Next I tried to view revision information:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/main/java/ca/sqlpower/architect/architectsession.j...@3394

returned:
svn: Could not resolve path /trunk/src/ca/ArchitectSession.java for history
I noticed the path at this point was wrong. The ArchitectSession.java file
is located at
/trunk/src/ca/sqlpower/architect.

Verifying revision information:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/architectsession.j...@3393

returned:
1600 fuerth /*
  2099 jeff...@sqlpower.ca  * Copyright (c) 2008, SQL Power Group Inc.
  2099 jeff...@sqlpower.ca  *
  2099 jeff...@sqlpower.ca  * This f
Since the revision before my commit caused the error I decided it would be
best to
reverse the change.

The first step I took to try and reverse the change was I went to Eclipse
and did a reverse
merge from r3394 to r3393. This reversed the file move but retrieving
revision information
was still failing:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/architectsession.j...@3395

returned:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history
The path to the file was now correct but the path still could not be
resolved.

Finally, I decided to try and remove the entire directory and copy
everything from r3393,
before the directory change.
I tried:
svn delete -m "removing all of src to check it back in to fix history."
https://power-architect.googlecode.com/svn/trunk/src
followed by:
svn copy https://power-architect.googlecode.com/svn/trunk/s...@3393
https://power-architect.googlecode.com/svn/trunk/src

However, this still resulted in:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


returning:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history

Any help in restoring my revision history would be greatly appreciated.

Thanks,

Thomas

Re: problem with peg revision

[Vincent Lefevre]

On 2010-03-25 13:06:56 -0400, David Weintraub wrote:
> I played around with svn info and pegged revisions, and had no
> problems. Have you've looked at the svn log? That might be a place to
> start and maybe help you understand when the name change took place.

The file name never changed.

> One of the issues our users run into when specifying pegged revisions
> is that they misstate the revision.
> 
> Let's say I removed directory "foo" and committed a new revision
> 10002. When you look at the svn log, you see that revision 10002 is
> where I removed "foo".
> 
> Sometimes my developers will do something like this:
> 
> $ svn info f...@10002
> 
> and get the message that they used an invalid URL. I point out that in
> this case, they need the revision BEFORE 10002:
> 
> $ svn info f...@10001
> 
> works.
> 
> Could there be something like that going on here?

No.

But it seems that my problem is a known limitation:

  Verify that the object's location (path-wise) in PEG-REV is the same
  as it is in OPERATIVE-REV. If that's the case, at least the two
  locations are known to be directly related, so perform the requested
  action on the location in OPERATIVE-REV. Otherwise, relatedness was
  not established, so error out with a loud complaint that no viable
  location was found. (Someday, we expect that Subversion will be able
  to handle this usage scenario with more flexibility and grace.)

This is the latter case.

One problem is that it seems to be impossible to specify an object
that was removed from the current directory (actually its ancestor),
just by using its name and some revision.

And in case you didn't see...

> On Thu, Mar 25, 2010 at 11:33 AM, Vincent Lefevre
>  wrote:
> > Hi,
> >
> > It seems that peg revisions do not work when a directory has been
> > renamed. For instance:
> >
> > $ svn info notes
> > Path: notes
> > Name: notes
> > URL: svn+ssh://mysvn/arith/stds-754/notes
 ^
> > Repository Root: svn+ssh://mysvn
> > Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
> > Revision: 35831
> > Node Kind: file
> > Schedule: normal
> > Last Changed Author: lefevre
> > Last Changed Rev: 19957
  ^
> > Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
> > Text Last Updated: 2010-01-04 19:18:16 +0100 (Mon, 04 Jan 2010)
> > Checksum: 06585f431d7af5737b91dcfacd4e7f6d
> >
> > $ svn info -r19957 notes
 ^
> > Path: notes
> > Name: notes
> > URL: svn+ssh://mysvn/doc/fp/stds-754/notes
 ^^
> > Repository Root: svn+ssh://mysvn
> > Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
> > Revision: 19957
> > Node Kind: file
> > Last Changed Author: lefevre
> > Last Changed Rev: 19957
> > Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
> >
> > $ svn info no...@19957
 ^
> > no...@19957:  (Not a valid URL)
> >
> > svn: A problem occurred; see other errors for details
> > zsh: exit 1     svn info no...@19957

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)