Re: Troubleshooting Gnome keyring

2012-12-20 Thread Nico Kadel-Garcia 
On Wed, Dec 19, 2012 at 12:25 PM, Mark Phippard  wrote:
> On Tue, Dec 18, 2012 at 10:42 PM, Nico Kadel-Garcia  wrote:
>> On Tue, Dec 18, 2012 at 11:09 AM, Mark Phippard  wrote:
>>> On Mon, Dec 17, 2012 at 8:17 PM, Aubrey Barnard  wrote:
>>>
 I am having trouble getting Subversion to work with the Gnome keyring and
 would like some advice on how to troubleshoot the situation. At this point 
 I
 have tried everything I can find (Google, these archives), so I need to 
 find
 how/where things are failing.

 I am using the svn+ssh protocol to access a server within my organization.
 Even with what I understand is the proper configuration, I am still 
 prompted
 for my SSH password and Subversion never mentions a keyring or asks for a
 keyring password. The environment is RHEL 6, so I expected this to work
 out-of-the-box with the default svn. More information is below.
>>>
>>> Subversion does not really do any authentication when you use SSH, so
>>> there are no credentials for it to cache and none of those settings
>>> come into play.
>>>
>>> When you use SSH, the authentication process is managed by your SSH
>>> client.  I think most Unix users use something like ssh-agent to
>>> manage their keys and I believe there are flavors of that which
>>> interact with a GUI such as GNOME.
>>
>> But the "gnome-keyring" is supposed to manage this for you with Gnome
>> up and running. Aubry, which Subversion are you using? I've published,
>> SRPM tools at https://github.com/nkadel/subversion-1.6.18-srpm which
>> you may find useful to build a fully equipped Subveriosn 1.6.18,
>> compatible with Red Hat's, but with all the latest features such as
>> gnome-keyring support as much as can be activated with RHEL 5.
>>
>> Alternatively, jump to RHEL 6 or Scientific Linux 6, both of with have
>> better support for such modern tools.
>
> There are integrations between OpenSSH and ssh-agent and GNOME
> keyring, however this has nothing to do with Subversion or the SVN
> binaries you are using.  It has to do with your SSH client.
> Subversion just spawns the SSH client and the rest is determined by
> that client.
>
> Subversion's GNOME keyring support applies to Subversion's password
> caching which does not apply when SSH is being used.

You've a point about the distinction, but I thought it was working
well with SSH passphrase requests when I used it last. I don't have a
local Subversion repo to play with. Aubry, can you activate an SSH key
for this and test using the SSH key?

It's not clear which svn+ssh setup our faithful narrator is using. The
security of direct user login with SSH passwords and local SSH
accounts on the Subversion server is well, it's a long standing
management problem. The Subversion "Red Book", sadly, only mentions
the correct solution of a designated "svn" user with SSH keys using
the "force-command" option as a kind of afterthought, and the results
are confusing. Because it's mentioned as a complex afterthought,
rather than as the recommended default, life gets confusing.

I am *not* going to get into the reasons why SSH authentication is
preferable to HTTPS here unless asked. I've been very vocal about it
for years, in the Subversion mailing lists.

Re: subversion Exception

2012-12-20 Thread Andy Levy 
On Thu, Dec 20, 2012 at 1:56 AM, Ravi Kant Sahu  wrote:

> I'm also facing same problem even in latest version (v1.7.10) of Tortoise
> SVN :
>
> Same problem as who? Please quote context.


> 
> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you were trying to do.
>

Please read this part & heed its request.


> But please first search the mailing list archives for the error message
> to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at
> http://subversion.apache.org/mailing-lists.html
>
>
Please read this part as well. Did you do any searching? In particular,
this result? http://comp.lang.xharbour.narkive.com/E09fABRc/svn-error


> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C):
>
> In file
>
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\update_editor.c'
>  line 1583: assertion failed (action == svn_wc_conflict_action_edit ||
> action
>  == svn_wc_conflict_action_delete || action ==
> svn_wc_conflict_action_replace)
> ---
> OK
> ---
> 
>
> --
>
> *Kind Regards*
> Ravikant Sahu
> Product Architect
> rs...@cordys.com
> www.cordys.com
> T +914066561094• M +919885046599
>  [image: Cordys]  - The Enterprise Cloud Platform
>

problem when upgrading my working copy

2012-12-20 Thread Pia Unte 

Hi,
I keep having problems when upgrading my working copy. This keeps 
popping up when I try upgrading.


I'm not sure what additional information you may need. Just tell me what
you need.

I'm not subscribed and would appreciate being explicitly Cc:ed in any 
responses.


Thanks.
Pia

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\entries.c'
 line 1666: assertion failed (parent_node || entry->schedule ==
 svn_wc_schedule_normal)
---
OK
---

Re: problem when upgrading my working copy

2012-12-20 Thread Philip Martin 
Pia Unte  writes:

> In file
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\entries.c'
>  line 1666: assertion failed (parent_node || entry->schedule ==
>  svn_wc_schedule_normal)

I think that's a new one.  Can you describe your working copy?  Can you
use Subversion 1.6 and run status?  Do you have adds, deletes, copies,
switches?  Is your working copy mixed revision?  Was there any output
before the assertion?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

RE: problem when upgrading my working copy

2012-12-20 Thread Bert Huijben 


> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: donderdag 20 december 2012 16:20
> To: Pia Unte
> Cc: users@subversion.apache.org
> Subject: Re: problem when upgrading my working copy
> 
> Pia Unte  writes:
> 
> > In file
> >  'D:\Development\SVN\Releases\TortoiseSVN-
> 1.7.10\ext\subversion\subversion\libsvn_wc\entries.c'
> >  line 1666: assertion failed (parent_node || entry->schedule ==
> >  svn_wc_schedule_normal)
> 
> I think that's a new one.  Can you describe your working copy?  Can you
> use Subversion 1.6 and run status?  Do you have adds, deletes, copies,
> switches?  Is your working copy mixed revision?  Was there any output
> before the assertion?

This is caused by upgrading an added directory without its parent directory.
Most likely caused by moving a single working copy directory.

This state (added to a parent that does not exist) is not supported by the
new working copy database introduced in 1.7. The database always requires
the root of the working copy to exist in the repository.

Bert

Re: problem when upgrading my working copy

2012-12-20 Thread Philip Martin 
"Bert Huijben"  writes:

> This is caused by upgrading an added directory without its parent directory.
> Most likely caused by moving a single working copy directory.
>
> This state (added to a parent that does not exist) is not supported by the
> new working copy database introduced in 1.7. The database always requires
> the root of the working copy to exist in the repository.

Hmm, yes:

$ svnadmin create repo
$ svn1.6 co file://`pwd`/repo wc
$ svn1.6 mkdir wc/A
$ mv wc/A wc2
$ svn st wc2
A   wc2
$ svn1.7 upgrade wc2
svn: E235000: In file '../src-1.7/subversion/libsvn_wc/entries.c' line 1666: 
assertion failed (parent_node || entry->schedule == svn_wc_schedule_normal)
Aborted

Does that look like the sort of working copy that triggered the original
report?  Does anybody use working copies like that?  Any supported for
that sort of working copy in 1.6 was accidental, it can't be committed
or updated.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Subversion 1.7.8 released

2012-12-20 Thread Ben Reser 
I'm happy to announce the release of Apache Subversion 1.7.8.
Please choose the mirror closest to you by visiting:

http://subversion.apache.org/download/#recommended-release

The SHA1 checksums are:

12c7d8d5414bba74c9777c4d1dae74f152df63c2 subversion-1.7.8.tar.bz2
1e298368cc2a73337eaaf192510afa5e88a097c8 subversion-1.7.8.tar.gz
65985725f8138cc18993a9088d4ad70df6c0d816 subversion-1.7.8.zip

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.7.8.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.7.8.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.7.8.zip.asc

For this release, the following people have provided PGP signatures:

   Philip Martin [2048R/ED1A599C] with fingerprint:
A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Paul T. Burba [4096R/56F3D7BC] with fingerprint:
1A0F E7C6 B3C5 F8D4 D0C4  A20B 64DD C071 56F3 D7BC
   Julian Foad [1024D/353E25BC] with fingerprint:
6604 5A4B 43BC F994   5728 351F 33E4 353E 25BC
   C. Michael Pilato [4096R/FE681333] with fingerprint:
753B 2F9D F717 FA23 A43E  E7C3 F5E0 F001 FE68 1333
   Branko Čibej [2048R/C8628501] with fingerprint:
8769 28CD 4954 EA74 87B6  B96C 29B8 92D0 C862 8501
   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Johan Corveleyn [4096R/010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
   Ben Reser [4096R/16A0DE01] with fingerprint:
19BB CAEF 7B19 B280 A0E2  175E 62D4 8FAD 16A0 DE01
   Julian Foad [4096R/4EECC493] with fingerprint:
6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493

Release notes for the 1.7.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.7.html

You can find the list of changes between 1.7.8 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.7.8/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

Re: problem when upgrading my working copy

2012-12-20 Thread Stefan Sperling 
On Thu, Dec 20, 2012 at 04:07:11PM +, Philip Martin wrote:
> "Bert Huijben"  writes:
> 
> > This is caused by upgrading an added directory without its parent directory.
> > Most likely caused by moving a single working copy directory.
> >
> > This state (added to a parent that does not exist) is not supported by the
> > new working copy database introduced in 1.7. The database always requires
> > the root of the working copy to exist in the repository.
> 
> Hmm, yes:
> 
> $ svnadmin create repo
> $ svn1.6 co file://`pwd`/repo wc
> $ svn1.6 mkdir wc/A
> $ mv wc/A wc2
> $ svn st wc2
> A   wc2
> $ svn1.7 upgrade wc2
> svn: E235000: In file '../src-1.7/subversion/libsvn_wc/entries.c' line 1666: 
> assertion failed (parent_node || entry->schedule == svn_wc_schedule_normal)
> Aborted
> 
> Does that look like the sort of working copy that triggered the original
> report?  Does anybody use working copies like that?  Any supported for
> that sort of working copy in 1.6 was accidental, it can't be committed
> or updated.

In any case, it shouldn't assert. It should print an error message
explaining what is wrong...

SOLVED: Re: Merge after looking at eligible revs w/ merginfo command erroneously merging from branch base

2012-12-20 Thread Eric Malkowski 
After looking at this some more, we had some svn:mergeinfo properties 
that were set at one layer below the branch / trunk levels from some 
developers simply working at the wrong level.  It spread like a virus 
through various branches taken since so  I used:


svn propget svn:mergeinfo -R -v svn://mmi-data/node_controller

to go through everywhere that had mergeinfo down one level and then had 
to check out just that directory and remove the svn:mergeinfo property 
with svn propdel and all is well -- the tool automatically uses the 
right set of changes to merge from trunk to branch in my example below.


What is really confusing is that the svn mergeinfo --show-revs eligible 
does not actually agree with what the merge does...  I view this as a 
bug, the mergeinfo could more correctly show before actually doing the 
merge that it would want to go back to where the branch was taken and 
get into trouble...  but it shows things as if they will be merged 
correctly, but then the merge command goes back too far and we get tree 
conflicts / file conflicts galore...


I'm feeling much better now -- things are cleaned up quite well and I 
think we'll be all set.


Hopefully this might help others that could run into similar issues.

Eric Malkowski wrote:

Hi Subverison Users List:

We're using Subversion client and server 1.6.15 exact version: svn, 
version 1.6.15 (r1038135)
We are doing the typical trunk and branch development outlined in the 
svn book -- i.e. cut a branch, do devel on branch w/ multiple merges 
of branch out to trunk, and finally do a re-integrate merge from 
branch back to trunk and stop using the branch -- cut another one.  
We've been very successful, but made a couple errors on one of our 
branches and cannot seem to get back on track -- here's the details:


We cut a branch devel_bugatti at revision r11567, here's the commit 
log from branch creation:


emalkowski@eric-lnx:/local/emalkowski/svn_merge$ svn log -v -r11567 
svn://mmi-data/node_controller


r11567 | monorato | 2012-04-26 16:06:04 -0400 (Thu, 26 Apr 2012) | 1 line
Changed paths:
   A /node_controller/branches/devel_bugatti (from 
/node_controller/trunk:11566)


So devel continued on branch and trunk and we did mess up on some 
merges from trunk to branch where the error was that the svn:mergeinfo 
property was NOT committed on two trunk to branch merges.  So it went 
as follows:


- One merge of trunk to branch done correct where the mergeinfo was 
committed after the merge.
- Second merge trunk to branch, developer committed all merged files, 
but missed commit of svn:mergeinfo prop update on devel_bugatti dir
- Third merge of trunk to branch, developer missed svn:mergeinfo 
again, didn't have any real problems with conflicts and branch devel 
is now done.


I attempted a merge from trunk to branch to prepare for branch retire 
and it keeps merging from branch creation r11567 to the HEAD of trunk 
-- this results in tree conflicts for files/dirs added on trunk, (that 
live on branch due to previous untracked merges w/o mergeinfo) and it 
leads to file conflicts / trying to merge more than it should.


So to try and fix this, I did a propedit on the dir devel_bugatti with 
the mergeinfo property to set the range from 11567 to 12199 which by 
examining logs from trunk and branch 12199 is the last thing committed 
to the trunk that was already merged to the branch.  The idea is to 
merge 12199 to HEAD changes on trunk to branch to only pick up what's 
changed on trunk since most recent merge that missed mergeinfo...  The 
commands that show what is merged from trunk to branch already and 
what is eligible look totally right (evidence changing mergeinfo range 
to 11567-12199 should work) -- but when doing the merge, it still goes 
back to when the branch was created and doesn't seem to use the 
svn:merginfo data!!!  Anyone have any idea why the merge command would 
behave different than what eligible says would be merged?  I'm going 
to start losing sleep over this any ideas greatly appreciated:


emalkowski@eric-lnx:/local/emalkowski/svn_merge/devel_bugatti$ svn 
proplist -v .

Properties on '.':
  svn:mergeinfo
/node_controller/branches/devel:1321-1564
/node_controller/branches/devel_delorean:11566-12027
/node_controller/branches/devel_ducati:1566-11563
/node_controller/branches/devel_emalkowski:1326-1449
/node_controller/branches/devel_monorato:1324-1451
/node_controller/branches/devel_rblack:1325-1456
/node_controller/branches/devel_rblack_bugatti_mpid:12091-12147
/node_controller/trunk:11567-12199

The last line is the interesting one that is tracking trunk -- by the 
way, before hand editing it, the 2nd number in the range was 12149 
which was the committed mergeinfo from the very first trunk to branch 
merge before the two messed up ones were done (and mergeinfo stayed at 
12149).


emalkowski@eric-lnx:/local/emalkowsk

non-canonical list addresses Re: Restoring a single numbered file into revs directory

2012-12-20 Thread Daniel Shahaf 
I've replied (tldr: yes, but probably hardware problems involved), and
my reply bounced since the list address used wasn't the canonical one.
So, I'm one bounce message richer, and my reply didn't get delivered to
list members.  Any reason we shouldn't just ban emails that don't use
the correct list address?

Re: For a large post-commit failed

2012-12-20 Thread Thorsten Schöning 
Guten Tag dhanushka ranasinghe,
am Freitag, 21. Dezember 2012 um 05:10 schrieben Sie:

> I got the following error when doing large commit , but the commit
> was successful , is there any reason for that. ?

Post commits run after commits and therefore can't stop those or what
is the reason of your question? The problem with your post commit hook
is described in the provided stack trace.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow