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

the eclipse cvs client allows to reject a change by simply clicking "mark the local file as merged", and commit it. There are multiple enhancement requests filed against sublicpse which get rejected because "svn does not offer such a feature via API" and "we (subclipse) do not tinker with your fil

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

On Mar 14, 9:38 pm, Ryan Schmidt wrote: > On Mar 14, 2011, at 13:57, rupert.thurner wrote: > > > the eclipse cvs client allows to reject a change by simply clicking > > "mark the local file as merged", and commit it. > > > There are multiple enhancement r

svn-1.6.x, serf: Error running context: Internal error.

i've a checked out, without externals, not using serf: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/ and get a: $ svn up --ignore-externals svn: Error running context: Internal error this is on solaris, after switching to serf in ~/.subversion. i am not sure if this should work without p

svn log knows about svn:external

hi, especially when continuous integration build one option to trigger the build is if something changed. usually this is easy as the repo version is increased. is there an easy way to find out if there is a change considering svn:externals as well? the only command i was aware of was svn log, bu

GnomeKeyring: not entering passwords

while looking for a possibility to help a user of subversion so he does not need to type the server password all the time, i got hinted to GnomeKeyring and seahorse. subversion offers to be compile with -- with-gnome-keyring option. what we finally want to have is a one time prompt on the command

Re: GnomeKeyring: not entering passwords

On Nov 3, 7:54 pm, Mark Phippard wrote: > On Thu, Nov 3, 2011 at 2:38 PM, rupert.thurner > wrote: > > > while looking for a possibility to help a user of subversion so he > > does not need to type the server password all the time, i got hinted > > to GnomeKeyring and

write to svn via https and ssh, svn server with one operating system user for ssh access

hi, i tried to search a little but i did not see it explicitely: 1. is it possible to access the same svn repository for writing via http(s) and ssh? 2. how would it be possible to configure svn so that only one operating system user is needed for ssh access, like e.g. github is doing? rupert.

Re: write to svn via https and ssh, svn server with one operating system user for ssh access

On Dec 16, 3:03 pm, Andy Levy wrote: > On Fri, Dec 16, 2011 at 08:56, rupert.thurner > wrote: > > hi, > > > i tried to search a little but i did not see it explicitely: > > > 1. is it possible to access the same svn repository for writing via > > h

svn cp (tag) should make an svn:external nail down to a revision

hi, what is the best possibility to create a tag of a folder containing svn:externals? the goal is that the external references do not point any more to the head, butto the fixed revision when the copy / tag was created? best regards, rupert.

Re: FeatureRequest: Improved svn:externals handling on Merge

On Tuesday, July 31, 2012 4:07:17 PM UTC+2, Stefan Sperling wrote: > > On Mon, Jul 30, 2012 at 10:13:37AM +0100, Marcel Hesselbarth wrote: > > Hi Developers, > > > > I'm redirected here from the tortoise mailing list, as they think this > > feature belongs to the area of the svn library. Perfo

SVN_SSH for java, svnkit, or others?

hi, i tried to find a way to define SVN_SSH for java, and i was not really able to find it with svnkit. also the eclipse subversive plugin does not offer to enter it. did i overlook something, or anybody knows a java client which is able to use any ssh tool? if somebody wonders why i'm asking thi

authentication realm "Internal"

hi, in .subversion/auth/svn.simple/ we have Internal and Subversion: repo the first one allows access to all repositories, the second one to a specific repository. how can one get the "Internal" realmstring in the authentication f

authorizing via ldap groups

hi, i was wondering, what is the best possibility to use ldap groups for authorizing access to svn on repositories itself, as well as on directory level. authentication is done via ssh as described in the documentation, no need to do this via ldap. i saw: http://svnbook.red-bean.com/en/1.7/svn