Nabble - Subversion Users

Re: Give us instructions to create a new repository with the branch code of a old repository

2009-11-28T15:37:50Z

On Nov 28, 2009, at 07:01, Lalitha Prasad wrote:

> Previously we have only one repository "repo1" in our svn repository directory and we made our WebDav to point directly to the repository itself, i.e. /home/repos/repo1.
>
> With our new requirement, we have created 2 new repositories repo1_new and repo2. Now we have changed the svnpath of webdav to point to the parent directory.
>
> Up to this every thing worked fine.
>
> But when we tried to switch our working copy to the new repo_new(both repo1 and repo_new have same code but with different versions), then we are getting error.
>
> Our repo1_new is like a mirror to the repo1.

How was repo1_new created from repo1? Do they have the same UUID? Do they have the same revision numbers?

> Detailed information:
> Previously, our workspace used to point to the url http://sample.com/svn/branches/branch1.
> Now we need to switch to the url http://sample.com/svn/repo1_new/trunk

You're trying to do two things at once. You need to do them separately. First you need to relocate the working copy so that portion of the URL that points to the root of the repository is updated:

svn switch --relocate http://sample.com/svn http://sample.com/svn/repo1_new

(the repository root used to be at /svn and now it is at /svn/repo1_new)

Then you can switch the part after the repository URL, if desired. For example if you want to switch from branch1 to trunk, you do:

svn switch http://sample.com/svn/repo1_new/trunk

(the working copy has now been switched from wherever it was (branches/branch1) to trunk)

> We have tried the command svn switch http://sample.com/svn/repo1_new/trunk from the workspace. This has thrown us error like this,
> Error:
> svn: 'http://sample.com/svn/branches/branch1'
> is not the same repository as
> 'http://sample.com/svn/repo1_new/trunk'
>
> How can solve this one and make my workspace to switch to the new url?

If the above doesn't help, then it sounds like they are not the same repository. If they aren't, then you can't switch or relocate; you must check out new working copies.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425142

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Can't "import" using admin account

2009-11-28T15:30:37Z

On Nov 28, 2009, at 15:41, brettr wrote:

> I'm on Mac OS X 10.6.2. When logged into my main admin account, I can't do an svn import into an existing repository. No errors appear but nothing ever imports. If I log out and into another account, svn import works and all files are added to the repository. Why would svn import behave differently between accounts? Especially an admin account?

What version of Subversion is this? How is the repository hosted -- http, https, svn, svn+ssh, file? What are the permissions on the repository files?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425140

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: seg fault when trying to load repo into Dropbox folder

2009-11-28T15:29:45Z

On Nov 28, 2009, at 13:29, Rich E wrote:

> I am trying to set up svn for some of my local projects in a Dropbox (https://www.dropbox.com/home#/) folder. I am getting a segmentation fault and I don't know why. This is what I did:
>
> Richard-Eakins-MacBook-Pro:Dropbox richardeakin$ svnadmin create ./svn
> Richard-Eakins-MacBook-Pro:Dropbox richardeakin$ cd ~/pd/externals/wacom
> Richard-Eakins-MacBook-Pro:externals richardeakin$ svn import wacom file:///Users/richardeakin/Dropbox/svn/pd/wacom -m "initial wacom pd external import"
> Segmentation fault

Since Dropbox is some kind of file sharing setup, that may be a problem. Subversion repositories should be hosted on disks attached to the server locally (or something that accurately simulates that, like a SAN). Storing a repository on an NFS share can work if the NFS implementation has good support for locking. I'm not sure what Dropbox uses under the hood so I can't say whether it should work or not. I do agree Subversion should not segfault. (What version of Subversion were you using, on what version of Mac OS X?) But I would still recommend you find a proper approved method of hosting your repository, and don't try to put it on Dropbox. For example there are many companies that specialize in offering Subversion repository hosting, if you don't have a server you can run Apache or svnserve on yourself.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425139

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Can't "import" using admin account

2009-11-28T13:41:33Z

I'm on Mac OS X 10.6.2. When logged into my main admin account, I can't do an svn import into an existing repository. No errors appear but nothing ever imports. If I log out and into another account, svn import works and all files are added to the repository. Why would svn import behave differently between accounts? Especially an admin account?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425133

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

seg fault when trying to load repo into Dropbox folder

2009-11-28T11:29:32Z

Hi,

I am trying to set up svn for some of my local projects in a Dropbox (https://www.dropbox.com/home#/) folder. I am getting a segmentation fault and I don't know why. This is what I did:

Richard-Eakins-MacBook-Pro:Dropbox richardeakin$ svnadmin create ./svn
Richard-Eakins-MacBook-Pro:Dropbox richardeakin$ cd ~/pd/externals/wacom
Richard-Eakins-MacBook-Pro:externals richardeakin$ svn import wacom file:///Users/richardeakin/Dropbox/svn/pd/wacom -m "initial wacom pd external import"
Segmentation fault

Can anyone help me get this working? Thanks!

Rich

Re: Give us instructions to create a new repository with the branch code of a old repository

2009-11-28T05:01:37Z

Hi All

I have got another scenario, where in i am feeling difficulty to switch the workspace to a new URL.

Previously we have only one repository "repo1" in our svn repository directory and we made our WebDav to point directly to the repository itself, i.e. /home/repos/repo1.

With our new requirement, we have created 2 new repositories repo1_new and repo2. Now we have changed the svnpath of webdav to point to the parent directory.

Up to this every thing worked fine.

But when we tried to switch our working copy to the new repo_new(both repo1 and repo_new have same code but with different versions), then we are getting error.

Our repo1_new is like a mirror to the repo1.

Detailed information:
Previously, our workspace used to point to the url http://sample.com/svn/branches/branch1.
Now we need to switch to the url http://sample.com/svn/repo1_new/trunk
We have tried the command svn switch http://sample.com/svn/repo1_new/trunk from the workspace. This has thrown us error like this,
Error:
svn: 'http://sample.com/svn/branches/branch1'
is not the same repository as
'http://sample.com/svn/repo1_new/trunk'

How can solve this one and make my workspace to switch to the new url?
Please help me in solving this problem

Thanks in advance

--
Thanks & Regards,
V. Lalitha Prasad,
Software Developer
Scube IT Solutions India Pvt. Ltd
www.scubian.com
lalith.prasad@...
(Cell) +91 9966282236
#4-1-319, 2nd Floor, Abids Road, Hyderabad - 01

Re: Question about creating patch

2009-11-27T19:46:02Z

Greetings, Neo Anderson!

> I participate in a project which uses svn as its repository and I do not
> have previlege to commit source back to the svn. And I encounter a problem.

> Previously I alway use command `svn diff > /tmp/jira_number.patch` to create
> patch. There is no problem if I just modify existing source code. Now due to
> I create several java source files which previously did not exist in the svn
> repository, using `svn diff > /tmp/jira_number.patch` won't create patch
> that contains newly created source files. For instance, in svn there
> contained files

> messaging
> + messagedriven + a.java/ b.java

> Now I add new files

> messaging
> + messagdriven + a.java/ b.java/ c.java
> + d.java
> + e.java

> Files like d.java, e.java and c.java won't be included in the
> jira_number.patch file if executing `svn diff > /tmp/jira_number.patch`. And
> I can't commit source so I can't do e.g. `svn add` to add source back to the
> repository.

> What is the better way (best practice) to create patch so the developers would be easier to apply or test patch?

Make an export of revision you're making patch for.
Make an export of your working copy with patch.
Use normal diff to produce patch.
It can assume non-existing files as ones having zero length.

--
WBR,
Andrey Repin (anrdaemon@...) 28.11.2009, <6:44>

Sorry for my terrible english...

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425021

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Serious Problem [Subversion]

2009-11-27T19:43:34Z

Greetings, Ezequias Rodrigues da Rocha!

> I am with a serious problem of tree conflict (I gess in my repository) and I
> can't delete a folder using tortoise.

> The message I got when I try to remove using repo-browswer is on the
> following link.

> The error I get when I try to comiit a deletion (on a cliente) is the one
> below:

> http://farm3.static.flickr.com/2521/4138380771_530d0ee860_o.jpg

> Commit
> Commit failed (details follow):
> Aborting commit: 'C:\Projetos\GISConnex\3-EXECUCAO\GisConnex\Fontes de
> Interface' remains in conflict

You have to resolve local conflicts before committing anything from working
copy.

--
WBR,
Andrey Repin (anrdaemon@...) 28.11.2009, <6:42>

Sorry for my terrible english...

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425020

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Question about creating patch

2009-11-27T19:09:20Z

Thanks for the advice.

I appreciate your help.

--- On Sat, 28/11/09, Ryan Schmidt <subversion-2009d@...> wrote:

> From: Ryan Schmidt <subversion-2009d@...>
> Subject: Re: Question about creating patch
> To: "Neo Anderson" <javadeveloper999@...>
> Cc: users@...
> Date: Saturday, 28 November, 2009, 2:08
> On Nov 27, 2009, at 19:17, Neo
> Anderson wrote:
>
> > I participate in a project which uses svn as its
> repository and I do not have previlege to commit source back
> to the svn. And I encounter a problem.
> >
> > Previously I alway use command `svn diff >
> /tmp/jira_number.patch` to create patch. There is no problem
> if I just modify existing source code. Now due to I create
> several java source files which previously did not exist in
> the svn repository, using `svn diff >
> /tmp/jira_number.patch` won't create patch that contains
> newly created source files. For instance, in svn there
> contained files
> >
> > messaging
> > + messagedriven + a.java/ b.java
> >
> > Now I add new files
> >
> > messaging
> > + messagdriven + a.java/ b.java/ c.java
> > + d.java
> > + e.java
> >
> >
> > Files like d.java, e.java and c.java won't be included
> in the jira_number.patch file if executing `svn diff >
> /tmp/jira_number.patch`. And I can't commit source so I
> can't do e.g. `svn add` to add source back to the
> repository.
> >
> > What is the better way (best practice) to create patch
> so the developers would be easier to apply or test patch?
>
> Either "svn add" the files first (that way they get
> included in the patch) or send the complete new files
> separately. Ask the project which way they prefer.
>
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425015

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Question about creating patch

2009-11-27T18:08:20Z

On Nov 27, 2009, at 19:17, Neo Anderson wrote:

> I participate in a project which uses svn as its repository and I do not have previlege to commit source back to the svn. And I encounter a problem.
>
> Previously I alway use command `svn diff > /tmp/jira_number.patch` to create patch. There is no problem if I just modify existing source code. Now due to I create several java source files which previously did not exist in the svn repository, using `svn diff > /tmp/jira_number.patch` won't create patch that contains newly created source files. For instance, in svn there contained files
>
> messaging
> + messagedriven + a.java/ b.java
>
> Now I add new files
>
> messaging
> + messagdriven + a.java/ b.java/ c.java
> + d.java
> + e.java
>
>
> Files like d.java, e.java and c.java won't be included in the jira_number.patch file if executing `svn diff > /tmp/jira_number.patch`. And I can't commit source so I can't do e.g. `svn add` to add source back to the repository.
>
> What is the better way (best practice) to create patch so the developers would be easier to apply or test patch?

Either "svn add" the files first (that way they get included in the patch) or send the complete new files separately. Ask the project which way they prefer.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425008

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Question about creating patch

2009-11-27T17:17:21Z

I participate in a project which uses svn as its repository and I do not have previlege to commit source back to the svn. And I encounter a problem.

Previously I alway use command `svn diff > /tmp/jira_number.patch` to create patch. There is no problem if I just modify existing source code. Now due to I create several java source files which previously did not exist in the svn repository, using `svn diff > /tmp/jira_number.patch` won't create patch that contains newly created source files. For instance, in svn there contained files

messaging
+ messagedriven + a.java/ b.java

Now I add new files

messaging
+ messagdriven + a.java/ b.java/ c.java
+ d.java
+ e.java

Files like d.java, e.java and c.java won't be included in the jira_number.patch file if executing `svn diff > /tmp/jira_number.patch`. And I can't commit source so I can't do e.g. `svn add` to add source back to the repository.

What is the better way (best practice) to create patch so the developers would be easier to apply or test patch?

Thanks.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2425006

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: make check failures

2009-11-27T15:06:51Z

On Nov 27, 2009, at 05:58, David Chamont wrote:

> I just installed python 2.4.6 and extracted cvs2svn-2.3.0. When I type "make check", I have the failures listed below. Should I worry ?
>
> FAIL: run-tests.py 68: eol settings and mime types together...variant 1
> FAIL: run-tests.py 69: eol settings and mime types together...variant 2
> FAIL: run-tests.py 70: eol settings and mime types together...variant 3
> FAIL: run-tests.py 71: eol settings and mime types together...variant 4
> FAIL: run-tests.py 72: test non-setting of cvs2svn:cvs-rev property
> FAIL: run-tests.py 73: test setting of cvs2svn:cvs-rev property
> FAIL: run-tests.py 74: test setting of svn:keywords property among others
> FAIL: run-tests.py 75: test setting of svn:ignore property
> FAIL: run-tests.py 90: test auto-props
> FAIL: run-tests.py 124: svn:ignore should vanish when .cvsignore does

You should probably ask the developers of cvs2svn; this list is for the core Subversion product.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424988

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Keeping common files in trunk and branch identical

2009-11-27T15:06:16Z

On Nov 27, 2009, at 07:36, Asbjørrn Sæbø wrote:

>> If you know ahead of time which parts are likely to be kept common
>> among all versions, the best approach might be to split them into
>> libraries that are maintained separately and referenced as externals
>> be all versions that use them.
>
> That is certainly a possibility. The problem with it is that keeping
> it fine grained enough creates quite some overhead, I think. Basically
> I want to do this on a file level.

File-level externals do exist in recent versions of Subversion, with some additional restrictions.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424987

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Cannot submit a changelist while obstructed item exists

2009-11-27T14:21:44Z

A file which has been obstructed by changing it to a symbolic link prevents
submitting changelists.

To repro, simply replace a file with a sym link of the same name, and then try
to submit a changelist which does not include the obstructed file.

Reproduced with SVN 1.6.4, 1.6.5, and 1.6.6.

Here is an unannotated list of commands which can serve as a script to repro the
problem (execute from within a pre-existing repo working copy):

      touch a.txt b.txt c.txt d.txt
      svn add a.txt b.txt c.txt d.txt
      svn commit -m "Add a, b, c, d"
      echo a >> a.txt
      echo b >> b.txt
      rm c.txt
      ln -s d.txt c.txt
      svn changelist cltest a.txt b.txt
      svn commit --changelist cltest -m "test"

Here is an annotated step-by-step repro:

Start with a couple modified files (a.txt & b.txt in this case):

      nick@nimble ~/test_repo $ ls -hal
      total 24K
      drwxr-xr-x   3 nick users 168 Sep 15 04:31 .
      drwxr-xr-x 146 nick users 7.5K Sep 15 04:16 ..
      drwxr-xr-x   6 nick users 216 Sep 15 04:31 .svn
      -rw-r--r--   1 nick users    4 Sep 15 04:24 a.txt
      -rw-r--r--   1 nick users    4 Sep 15 04:24 b.txt
      -rw-r--r--   1 nick users    2 Sep 15 04:31 c.txt
      -rw-r--r--   1 nick users    2 Sep 15 04:31 d.txt
      nick@nimble ~/test_repo $ svn status
      M       b.txt
      M       a.txt

Obstruct a 3rd file (c.txt) by changing it to a symlink:

      nick@nimble ~/test_repo $ rm c.txt
      nick@nimble ~/test_repo $ ln -s d.txt c.txt

      nick@nimble ~/test_repo $ ls -hal
      total 20K
      drwxr-xr-x   3 nick users 168 Sep 15 04:32 .
      drwxr-xr-x 146 nick users 7.5K Sep 15 04:16 ..
      drwxr-xr-x   6 nick users 216 Sep 15 04:31 .svn
      -rw-r--r--   1 nick users    4 Sep 15 04:24 a.txt
      -rw-r--r--   1 nick users    4 Sep 15 04:24 b.txt
      lrwxrwxrwx   1 nick users    5 Sep 15 04:32 c.txt -> d.txt
      -rw-r--r--   1 nick users    2 Sep 15 04:31 d.txt
      nick@nimble ~/test_repo $ svn status
      M       b.txt
      ~       c.txt
      M       a.txt

Place the modified files (a.txt & b.txt) in a changelist:

      nick@nimble ~/test_repo $ svn cl cltest a.txt b.txt
      Path 'a.txt' is now a member of changelist 'cltest'.
      Path 'b.txt' is now a member of changelist 'cltest'.

      nick@nimble ~/test_repo $ svn status
      ~       c.txt

      --- Changelist 'cltest':
      M       b.txt
      M       a.txt

Attempt to commit the changelist:

      nick@nimble ~/test_repo $ svn commit --changelist cltest
      svn: Commit failed (details follow):
      svn: Entry '/home/nick/test_repo/c.txt' has unexpectedly changed special
status

This failure is unexpected, since the obstructed file is not in the changelist
which is being committed.

From the thread at
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2383349,
I've confirmed this works as expected if the obstruction is caused by changing
the file to a directory. So I suspect this issue is due to obstructions which
are caused by changing to a sym link.

Nick

Serious Problem [Subversion]

2009-11-27T11:44:24Z

Hi Subversion users.

I am with a serious problem of tree conflict (I gess in my repository) and I can't delete a folder using tortoise.

The message I got when I try to remove using repo-browswer is on the following link.

The error I get when I try to comiit a deletion (on a cliente) is the one below:

http://farm3.static.flickr.com/2521/4138380771_530d0ee860_o.jpg

Commit
Commit failed (details follow):
Aborting commit: 'C:\Projetos\GISConnex\3-EXECUCAO\GisConnex\Fontes de
Interface' remains in conflict

Sincerely
Ezequias R. da Rocha

Re: Future support to real tags and real branches?

2009-11-27T08:55:26Z

Ryan Schmidt <subversion-2009d@...> writes:

[...]

> I too find myself using "svn info" to find a working copy's URL to
> then edit that URL on the command line -- not usually for switching
> but for merging in my case, but the idea is the same. It would be
> nice to be able to specify a relative URL at the command line,

A shell script could do this work for you. Here is one that
calculates the new URL assuming the first component is ..:

#!/bin/sh

svn_url="`svn info |grep ^URL: |awk '{ print $2}'`"
svn_parent_url="`dirname "$svn_url"`"
svn_new_url="$svn_parent_url/$1"
echo "$svn_new_url"

So, for example, running it with a parameter of "branches/foozle" will
output the base URL with the last component removed, and
"branches/foozle" in its place.

Not exactly what the OP wanted, but maybe close enough to be a good
start.

-----Scott.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424921

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Using temporary branches and mergeinfo properties

2009-11-27T08:15:12Z

Igor Markovic wrote:
> - Now we need to merge the fixed bugs from the branch back to the trunk. (so we just merge revisions back to the trunk. Not the whole branch)

I guess sometimes it will be the whole branch anyway, because you merge
up all bug fixes, and sometimes it will be only some revisions, because
some bug fixes are being handled more fundamentally, right?

> This will cause all kind of mergeinfo properties on unchanged files.

No. Only if you merge parts of a revision: subdirectories or files in
changesets only. Avoid the need for that. When you fix bug A and bug B,
commit them separately so that you can merge the changes separately, but
still merge the whole changeset at once. Or if you do need to merge a
piece, keep track of it yourself and don't commit mergeinfo on the parts.

--
Stein

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424885

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: password-stores = keychain on MacOSX

2009-11-27T07:44:30Z

Hum, everytime that I log from my linux box using ssh. I then tries to
svn up, it makes the keychain/password fails. I wonder why from a ssh
session keychain+svn stopped working.

On Fri, Nov 27, 2009 at 4:26 PM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:

> I found the answer here:
>
> http://www.friday.com/bbum/2006/09/12/subversion-14-adds-keychain-support/
>
> "If you remember all of your repository passwords, simply delete the
> ~/.subversion/auth/svn.simple directory."
>
> Deleting the directory was the key...
>
> On Mon, Nov 23, 2009 at 6:04 PM, Mathieu Malaterre
> <mathieu.malaterre@...> wrote:
>> Hi there,
>>
>> I am on MacOSX., here is my config files:
>>
>> $ cat .subversion/config
>> password-stores = keychain
>>
>> $ cat .subversion/servers
>> store-passwords = yes
>> store-plaintext-passwords = no
>>
>> Using:
>>
>> $ svn --version
>> svn, version 1.6.2 (r37639)
>> compiled May 20 2009, 01:36:41
>>
>>
>> But still anytime I am doing a 'svn up', it ask me for my password. I
>> am a complete newbie on MacOSX, so I may have been missing a command
>> on how to setup this keychain thing on macosx. Any documentation I
>> missed ?
>>
>> Thanks,
>> --
>> Mathieu
>>
>
>
>
> --
> Mathieu
>

--
Mathieu

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424879

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: password-stores = keychain on MacOSX

2009-11-27T07:26:25Z

I found the answer here:

http://www.friday.com/bbum/2006/09/12/subversion-14-adds-keychain-support/

"If you remember all of your repository passwords, simply delete the
~/.subversion/auth/svn.simple directory."

Deleting the directory was the key...

On Mon, Nov 23, 2009 at 6:04 PM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:

> Hi there,
>
> I am on MacOSX., here is my config files:
>
> $ cat .subversion/config
> password-stores = keychain
>
> $ cat .subversion/servers
> store-passwords = yes
> store-plaintext-passwords = no
>
> Using:
>
> $ svn --version
> svn, version 1.6.2 (r37639)
> compiled May 20 2009, 01:36:41
>
>
> But still anytime I am doing a 'svn up', it ask me for my password. I
> am a complete newbie on MacOSX, so I may have been missing a command
> on how to setup this keychain thing on macosx. Any documentation I
> missed ?
>
> Thanks,
> --
> Mathieu
>

--
Mathieu

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424869

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Commiting binary file on network/Samba disk - bad file permission inside .svn/props

2009-11-27T07:08:26Z

http://tortoisesvn.tigris.org/faq.html#samba I think this applies to
the regular svn client as well.

On Fri, Nov 27, 2009 at 6:05 AM, Michal Jurosz <rootmj_konf@...> wrote:

> Hi. My guess: Committing binary file (from Windows on Samba disk) create
> temp file inside .svn/props with bad permission (no write access for
> user). Should I report this as bug?
>
> # --------------------------------------------------------------------
> # Commiting binary file on network/Samba disk - bad file permission
> inside .svn/props.
> # Commiting text files is ok. So probably no Samba config problem.
> # Probably very old regression (from 1.4?). Samba config wasn't changed
> since it works.
>
> # W:\ is Linux Samba disk mouted as network drive to WinXP
>
> # on WinXP client
>
> W:\>cd test-repository
> W:\test-repository>echo text content > favicon.txt
> W:\test-repository>svn add favicon.txt
> A favicon.txt
>
> W:\test-repository>svn ci -m"text file is ok" favicon.txt
> Adding favicon.txt
> Transmitting file data .
> Committed revision 99.
>
> W:\test-repository>
>
> W:\test-repository>svn add favicon.ico
> A (bin) favicon.ico
>
> W:\test-repository>svn ci favicon.ico -m"image (binary file)"
> Adding (bin) favicon.ico
> Transmitting file data .svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: In directory 'W:\test-repository'
> svn: Error processing command 'committed' in 'W:\test-repository'
> svn: Can't move 'W:\test-repository\.svn\props\favicon.ico.svn-work' to
> 'W:\test-repository\.svn\prop-base\favicon.ico.svn-base': Access denied.
>
> W:\test-repository>svn cleanup
> svn: In directory '.'
> svn: Error processing command 'committed' in '.'
> svn: Can't move '.svn\props\favicon.ico.svn-work' to
> '.svn\prop-base\favicon.ico.svn-base': Access denied.
>
>
> # on Linux (Samba) server
>
> [root@ent data]# cd test-repository/
>
> [root@ent test-repository]# ls -al .svn/props/favicon.ico.svn-work
> -r-xr--r-- 1 vyvoj vyvoj 53 Aug 19 12:28 .svn/props/favicon.ico.svn-work
>
> [root@ent test-repository]# chmod u+w .svn/props/favicon.ico.svn-work
>
>
> # on WinXP client
>
> W:\test-repository>svn cleanup
> W:\test-repository>
>
> # --------------------------------------------------------------------
>
> # Bypass ("Solution")
> # Add 'force create mode = 0664' to Samba config
> # Run 'service smb restart'
>
> W:\test-repository>svn add favicon.ico
> A (bin) favicon.ico
>
> W:\test-repository>svn ci favicon.ico -m"image (binary file)"
> Adding (bin) favicon.ico
> Transmitting file data .
> Committed revision 104.
>
> --
> S pozdravem Michal Jurosz
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424830
>
> Please start new threads on the <users@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424864

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Keeping common files in trunk and branch identical

2009-11-27T05:36:13Z

> Date: Thu, 26 Nov 2009 10:12:55 -0600
> Subject: Re: Keeping common files in trunk and branch identical
> From: lesmikesell@...
> To: gaffe_1@...
>
> On Thu, Nov 26, 2009 at 8:10 AM, Asbjørrn Sæbø wrote:
>> I would like to have a branch for a different variant of our software.
>> In the branch, some of the files will be changed. The other files I
>> would like to keep identical between trunk and the branch. That is,
>> I would like to avoid the parallel maintenance of the same file in
>> the trunk and the branch. [...]

> If you know ahead of time which parts are likely to be kept common
> among all versions, the best approach might be to split them into
> libraries that are maintained separately and referenced as externals
> be all versions that use them.

That is certainly a possibility. The problem with it is that keeping
it fine grained enough creates quite some overhead, I think. Basically
I want to do this on a file level.

Asbjørn Sæbø

_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424844

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

RE: Keeping common files in trunk and branch identical

2009-11-27T05:32:35Z

----------------------------------------

> From: beppler@...
> Date: Thu, 26 Nov 2009 14:00:06 -0200
> Subject: Re: Keeping common files in trunk and branch identical
> To: blair@...
> CC: gaffe_1@...; users@...
>
> I think that he wants something like the "share" feature of Visual Source Safe.
>
> The file or project (directory) that is shared works like symlink
> where you can change the contents of the file on both ends and the
> change is visible on both ends. If you want to stop the share you
> select the "branch" command an then they starts to have separated
> contents again.

That seems quite like what I am thinking of, yes. Is anything like
this possible in Subversion?

Asbjørn Sæbø

_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424843

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

RE: Keeping common files in trunk and branch identical

2009-11-27T05:30:32Z

----------------------------------------

> Subject: Re: Keeping common files in trunk and branch identical
> From: blair@...
> Date: Thu, 26 Nov 2009 07:42:34 -0800
> CC: users@...
> To: gaffe_1@...
>
>
> On Nov 26, 2009, at 6:10 AM, Asbjørrn Sæbø wrote:
>
>> I would like to have a branch for a different variant of our
>> software. In the branch, some of the files will be changed.
>> The other files I would like to keep identical between trunk
>> and the branch. [...]

> So you're looking for a feature where if any portion of a file
> has been changed in the branch then merges from the trunk for
> that file are not applied, even if the branch and trunk
> modifications affected different portions of the file?

NO, it was more the opposite, that if a file is _not_ changed,
it would actually _be_ the same file in both the trunk and the
branch. (Yes, I know SVN branches do not really make copies
until you write to the file in the branch, but that is not really
visible for the user. If you have module A in the trunk, and
also module A in the branch, you can not know (without diffing or
carefully checking logs) whether they are identical or not any
more, even if they have the same ancestor.

Actually, we do not do much merging between branches. In the
past, such operations have been somewhat painful, with
TortoiseSVN requireing some manual control and intervenation.
Also, how do you really track what has been merged here and
there?

ASbjørn Sæbø

_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424842

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Commiting binary file on network/Samba disk - bad file permission inside .svn/props

2009-11-27T05:05:58Z

Hi. My guess: Committing binary file (from Windows on Samba disk) create
temp file inside .svn/props with bad permission (no write access for
user). Should I report this as bug?

# --------------------------------------------------------------------
# Commiting binary file on network/Samba disk - bad file permission
inside .svn/props.
# Commiting text files is ok. So probably no Samba config problem.
# Probably very old regression (from 1.4?). Samba config wasn't changed
since it works.

# W:\ is Linux Samba disk mouted as network drive to WinXP

# on WinXP client

W:\>cd test-repository
W:\test-repository>echo text content > favicon.txt
W:\test-repository>svn add favicon.txt
A favicon.txt

W:\test-repository>svn ci -m"text file is ok" favicon.txt
Adding favicon.txt
Transmitting file data .
Committed revision 99.

W:\test-repository>

W:\test-repository>svn add favicon.ico
A (bin) favicon.ico

W:\test-repository>svn ci favicon.ico -m"image (binary file)"
Adding (bin) favicon.ico
Transmitting file data .svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory 'W:\test-repository'
svn: Error processing command 'committed' in 'W:\test-repository'
svn: Can't move 'W:\test-repository\.svn\props\favicon.ico.svn-work' to
'W:\test-repository\.svn\prop-base\favicon.ico.svn-base': Access denied.

W:\test-repository>svn cleanup
svn: In directory '.'
svn: Error processing command 'committed' in '.'
svn: Can't move '.svn\props\favicon.ico.svn-work' to
'.svn\prop-base\favicon.ico.svn-base': Access denied.

# on Linux (Samba) server

[root@ent data]# cd test-repository/

[root@ent test-repository]# ls -al .svn/props/favicon.ico.svn-work
-r-xr--r-- 1 vyvoj vyvoj 53 Aug 19 12:28 .svn/props/favicon.ico.svn-work

[root@ent test-repository]# chmod u+w .svn/props/favicon.ico.svn-work

# on WinXP client

W:\test-repository>svn cleanup
W:\test-repository>

# --------------------------------------------------------------------

# Bypass ("Solution")
# Add 'force create mode = 0664' to Samba config
# Run 'service smb restart'

W:\test-repository>svn add favicon.ico
A (bin) favicon.ico

W:\test-repository>svn ci favicon.ico -m"image (binary file)"
Adding (bin) favicon.ico
Transmitting file data .
Committed revision 104.

--
S pozdravem Michal Jurosz

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424830

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

make check failures

2009-11-27T03:58:55Z

Hi All,

I just installed python 2.4.6 and extracted cvs2svn-2.3.0. When I type "make check", I have the failures listed below. Should I worry ?

FAIL: run-tests.py 68: eol settings and mime types together...variant 1
FAIL: run-tests.py 69: eol settings and mime types together...variant 2
FAIL: run-tests.py 70: eol settings and mime types together...variant 3
FAIL: run-tests.py 71: eol settings and mime types together...variant 4
FAIL: run-tests.py 72: test non-setting of cvs2svn:cvs-rev property
FAIL: run-tests.py 73: test setting of cvs2svn:cvs-rev property
FAIL: run-tests.py 74: test setting of svn:keywords property among others
FAIL: run-tests.py 75: test setting of svn:ignore property
FAIL: run-tests.py 90: test auto-props
FAIL: run-tests.py 124: svn:ignore should vanish when .cvsignore does

David.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424818

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

RE: Using temporary branches and mergeinfo properties

2009-11-27T01:41:38Z

Sorry that I didn't replied for a while. I didn't noticed there were any replies on my message.

Ok, I'll try to explain it a bit more:
- All developers work on the trunk.
- After all features are in we have a feature stop and branch the whole trunk.
- Most developers will now continue to work on the trunk and add new features for future releases.
- We do some small bug fixing on the branch and when everything is working as it should, we tag the brach and release the product.

Till here everything is working as expected.

- Now we need to merge the fixed bugs from the branch back to the trunk. (so we just merge revisions back to the trunk. Not the whole branch)

This will cause all kind of mergeinfo properties on unchanged files.

We also sometimes work the other way around. We sometimes fix bugs on the trunk or add new features to the trunk that need to be merged to the branch (so we can release a service pack containig fixes/new feature based on the old version of the software). This will also cause a lot of empty mergeinfo properties for a lot of files.

Server: 1.6.5
Client: TurtoiseSVN 1.6.5, Subversion 1.6.5 (commandline tool)

It even goes wrong when I self create a branch, do some changes on that branch and merge those changes back to the trunk on the same computer (so no other/older version of SVN are used in between)

I noticed that it sometimes can help if I turn on the 'Ignore ancestry' checkbox when merging.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424808

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Expected FS format '2'; found format '4' error

2009-11-27T00:56:08Z

Hello,

Yes, you were absolutely right. A rather stupid error---I realised that
the user I was logging in as via svn had correct macports (/opt/local)
paths set in .profile but didn't have any .bashrc. I guess in the
non-interactive version of the shell it wasn't sourcing .profile so was
defaulting to the wrong installation of svn.

Thanks for your help, problem now resolved.

On Thu, 26 Nov 2009, Kevin Grover wrote:

> I suspect that you have a path problem: the ssh session is probably using a
> path that gets you an old (default installed?) version of svn.
>
> On Thu, Nov 26, 2009 at 5:22 AM, Stuart Reeves <stuart@...> wrote:
>
>> Hi
>>
>> I think this is a common problem, and have found relevant answers on the
>> web and on the mailing lists, however nothing seems to have worked for
>> this problem yet, so I apologise if I have missed something obvious.
>> Anyway.
>>
>> I'm running svn on two Macs (toga, the client machine and float, the
>> server are running OS X and OS X Server respectively). The server's
>> repository has been working fine for a long time. I access the repo via
>> ssh (i.e., the svn+ssh method). Then something happened and I get the
>> following message when performing vital svn operations (e.g., up, ci,
>> etc.):
>>
>> [stuartn@toga:~/doc]$ svn up
>> Password:
>> svn: Expected FS format '2'; found format '4'
>>
>> Both the server and the client have their svn package compiled from the
>> latest version available on macports, i.e.,
>>
>> [stuartn@toga:~/doc]$ svn --version
>> svn, version 1.6.5 (r38866)
>> compiled Nov 17 2009, 18:14:25
>>
>> I have hunted around the web for a solution, but it seems like the
>> recommendation everywhere is to ensure that my svnadmin and svn commands
>> are all the right version. Unfortunately, both on the client and the
>> server have identical versions of svn, svnadmin and all the other tools.
>>
>> As far as I can tell, svnserve is running ok on the server:
>>
>> [stuart@float:/Shared]$ pstree | grep svnserve
>> |--= 00114 root /opt/local/bin/svnserve --daemon --root /usr/local/svn
>>
>> I even checked the format of the repo to make sure I hadn't done anything
>> stupid (like created the repo with an older version of svn that was
>> already on OS X):
>>
>> [stuart@float:/Shared]$ cat svn/format
>> 5
>>
>> As someone noted on a forum, there are indeed two copies of svn on the
>> server, however the macports build is being pointed at for everything:
>>
>> [stuart@float:~]$ which svnserve
>> /opt/local/bin/svnserve
>> [stuart@float:~]$ which svnadmin
>> /opt/local/bin/svnadmin
>> [stuart@float:~]$ which svn
>> /opt/local/bin/svn
>>
>> I have tried removing subversion from both the server and the client to
>> use the version of svn found on OS X in /usr/bin (including restarting
>> svnserve on the server to ensure it points at /usr/bin/svnserve). This
>> produces the same result (i.e., the error).
>>
>> I'm sure there *must* be something I'm missing but I can't figure out what
>> it might be. Any help is much appreciated...
>>
>>
>> Stuart Reeves
>> ---
>> Researcher
>> Dept. Computing Science, University of Glasgow
>> stuart@...
>> http://www.dcs.gla.ac.uk/~stuartr <http://www.dcs.gla.ac.uk/%7Estuartr>
>>
>> ------------------------------------------------------
>>
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424593
>>
>> Please start new threads on the <users@...> mailing
>> list.
>> To subscribe to the new list, send an empty e-mail to <
>> users-subscribe@...>.
>>
>

Stuart Reeves
---
Researcher
Dept. Computing Science, University of Glasgow
stuart@...
http://www.dcs.gla.ac.uk/~stuartr

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424796

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Want to check for any Security update for Subversion 1.4.5

2009-11-27T00:04:04Z

On Fri, Nov 27, 2009 at 02:23:36AM +0530, Satheesh Kumar2 wrote:
> Hi,
>
> I am Satheesh from IBM, i am supporting Subversion 1.4.5 for one of our
> customer. we have yearly checks for any security update for the products
> that we install and support for our customers.
> Could you please let me know if any security update relased for the
> Subversion 1.4.5.

1.5.7 and 1.6.4 were security fix releases (CVE-2009-2411).
The vendor you are getting 1.4.5 from may have 1.4.x patches for this
problem, but 1.4.x is no longer supported by the Subversion project.
The project only supports two stable releases at a time, and in
practice, the older of the two gets little attention and receives
critical securify fixes only.

You should update to the latest 1.6.x release if possible.

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424783

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Manual file copy to set up a Working copy?

2009-11-26T22:46:17Z

On Nov 26, 2009, at 20:45, Michael.Mowbray@... wrote:

> I have a 3.8GB working copy of a repository that I need to set up on a remote computer down a 4Mbit link from the Subversion server. Rather than ‘svn checkout’ the working copy across this link, is it possible to take the local created working copy, burn it to DVD, hand carry it to the remote computer, copy it to disk there and end up with a valid working copy at the remote computer?

Yes, that should work fine.

But note that data is compressed when transmitted over the wire, and also a working copy contains a complete redundant set of all files, so the amount of data transmitted over the network would be only a fraction of the 3.8-GB working copy size. (What fraction depends on how compressable your data is.)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424773

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Want to check for any Security update for Subversion 1.4.5

2009-11-26T22:19:29Z

On Fri, Nov 27, 2009 at 2:23 AM, Satheesh Kumar2 <sathkum4@...> wrote:

Hi,

I am Satheesh from IBM, i am supporting Subversion 1.4.5 for one of our customer. we have yearly checks for any security update for the products that we install and support for our customers.
Could you please let me know if any security update relased for the Subversion 1.4.5.

Its time to update as Subversion 1.4.x is no more supported.

--
Vishwajeet Singh
+91-9657702154 | dextrous85@... | http://singhvishwajeet.com
Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet

Re: question about "svn diff"+"ignore files" (.orig/.rej/~)

2009-11-26T21:24:37Z

2009/11/21 Alfred Perlstein <bright@...>:

> Hello,
>
> We have a script that invokes "svn diff" and then annotates
> the output for us.
>
> One thing I noticed is that unlike CVS, when invoked on
> a "should be ignored file", basically a file that matches
> *.orig, *.rej and *~, then "svn diff" will emit that file
> like so:
>
> ? foo.orig
>
> CVS however will not emit anything.
>
> Now both SVN and CVS will not emit anything if "diff" is invoked
> on the containing directory.
>
> My basic issue is that I'm not sure what to do...
>
> Because of the "? file.orig" output of SVN, my program assumes
> that this are files that need adding.
>
> So:
> 1) any ideas?
> 2) Is there some way to query SVN about the files that should be ignored
> so that I can filter them in my program?
> 3) Is there a way to get "svn diff" to ignore the file (generate ZERO output)
> when this is a file that should be ignored like "cvs diff"?
>
> thank you,
> --

I think that you can add those name patterns to the global-ignores
property in the Subversion configuration file. That is

/etc/subversion/config
and
~/.subversion/config

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

The *.orig pattern is not included in the default value of
global-ignores (while *.rej and *~ are there).

Also, it is usually recommended to use language bindings, instead of
trying to parse svn command output.

Best regards,
Konstantin Kolinko

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424757

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Re: Future support to real tags and real branches?

2009-11-26T18:59:35Z

On Thu, Nov 26, 2009 at 8:56 PM, Ryan Schmidt
<subversion-2009d@...> wrote:

>> This was added in 1.6 and it is purely a client feature so it works
>> with an server version. The syntax is:
>>
>> $ svn switch ^/branches/mybranch
>
> The release notes say "^/" is relative to the repository root, not the working copy URL.
>
> http://subversion.tigris.org/svn_1.6_releasenotes.html#repository-root-relative-urls
>
> In the example given above, there are presumably many projects in a deeply nested hierarchy in a single repository.

Right. I did not catch that.

--
Thanks

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

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424742

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.

Manual file copy to set up a Working copy?

2009-11-26T18:45:01Z

I have a 3.8GB working copy of a repository that I need to set up on a remote computer down a 4Mbit link from the Subversion server. Rather than ‘svn checkout’ the working copy across this link, is it possible to take the local created working copy, burn it to DVD, hand carry it to the remote computer, copy it to disk there and end up with a valid working copy at the remote computer?

Many thanks in advance,

Michael Mowbray

Technical Support Specialist
Lihir Services Australia Pty Ltd

2009-11-26T18:37:10Z

Re: Expected FS format '2'; found format '4' error

2009-11-26T18:09:18Z

On Nov 26, 2009, at 07:22, Stuart Reeves wrote:

> I'm running svn on two Macs (toga, the client machine and float, the
> server are running OS X and OS X Server respectively). The server's
> repository has been working fine for a long time. I access the repo via
> ssh (i.e., the svn+ssh method). Then something happened and I get the
> following message when performing vital svn operations (e.g., up, ci,
> etc.):
>
> [stuartn@toga:~/doc]$ svn up
> Password:
> svn: Expected FS format '2'; found format '4'
>
> Both the server and the client have their svn package compiled from the
> latest version available on macports, i.e.,
>
> [stuartn@toga:~/doc]$ svn --version
> svn, version 1.6.5 (r38866)
> compiled Nov 17 2009, 18:14:25
>
> I have hunted around the web for a solution, but it seems like the
> recommendation everywhere is to ensure that my svnadmin and svn commands
> are all the right version. Unfortunately, both on the client and the
> server have identical versions of svn, svnadmin and all the other tools.
>
> As far as I can tell, svnserve is running ok on the server:
>
> [stuart@float:/Shared]$ pstree | grep svnserve
> |--= 00114 root /opt/local/bin/svnserve --daemon --root /usr/local/svn

Because you are using svn+ssh, svnserve will be automatically started for each connection and closed afterward. Any svnserve daemon you've manually started will not be used for anything.

> I even checked the format of the repo to make sure I hadn't done anything
> stupid (like created the repo with an older version of svn that was
> already on OS X):
>
> [stuart@float:/Shared]$ cat svn/format
> 5

Wrong format file: the one it's talking about is in svn/db/format, which should confirm that the db format is 4 as the message stated.

> As someone noted on a forum, there are indeed two copies of svn on the
> server, however the macports build is being pointed at for everything:
>
> [stuart@float:~]$ which svnserve
> /opt/local/bin/svnserve
> [stuart@float:~]$ which svnadmin
> /opt/local/bin/svnadmin
> [stuart@float:~]$ which svn
> /opt/local/bin/svn
>
> I have tried removing subversion from both the server and the client to
> use the version of svn found on OS X in /usr/bin (including restarting
> svnserve on the server to ensure it points at /usr/bin/svnserve). This
> produces the same result (i.e., the error).

As Kevin said, when you're connecting via svn+ssh, the PATH doesn't contain /opt/local/bin, therefore it's using the svnserve in /usr/bin, which is too old to understand a version-4 repository database.

To set up your modified PATH so that it is used by noninteractive shells, such as the one started by the svn+ssh connection, I believe you need to set it in the ~/.bashrc of whatever user you're connecting to the server as. The MacPorts installer sets the PATH in your ~/.profile or ~/.bash_profile, but those aren't used by noninteractive shells.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424731

Please start new threads on the <users@...> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe@...>.