authorizing via ldap groups

[rupert.thurner]

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-book.html#svn.serverconfig.pathbasedauthz
 


for http i saw mod_authnz_ldap and:
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.httpd.authz.perdir

rupert

authentication realm "Internal"

[rupert.thurner]

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 file?

rupert.

SVN_SSH for java, svnkit, or others?

[rupert.thurner]

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 this: corporates sometimes think
they need their "own" way of authenticating, e.g. using tectia ssh, or
putty ssh, or kerberos enabled ssh.

rupert.

Re: FeatureRequest: Improved svn:externals handling on Merge

[rupert.thurner]

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. Performing some 
> > searches shows that I'm not the only one with this problem, even it it 
> > seems to be never posted here. 
> > 
> > The basic problem I have is I have a Project with svn:externals 
> > defined pointing into the same SVN. When I now make a tortoiseSVN 
> > commit the files changed inside the svn:externals folders are included 
> > - so all works great. 
> > 
> > If I now try to merge these commit into a other checkout the changes 
> > inside the svn:externals are not merged, they are silently ignored. I 
> > need to do a separate merge at the svn:externals folders. Doing so 
> > works fine, but why having to do this manually? As externals are 
> > silently included into commits it is easily overseen that a commit 
> > includes externals at merging. So if these externals are not merged or 
> > at least warned while merging they will be overseen -> an great source 
> > for new bugs... 
> > 
> > The merge of svn:externals is not done automatically independent of if 
> > the folder at the merge target is an linked svn:externals folder or a 
> > real folder. 
> > 
> > 
> > 
> > Now a detailed example for better visualisation: 
> > I have the following svn structure: 
> > svn://svn/test/main/trunc 
> >   svn:external Propery: svn://svn/test/sub/trunc sub 
> >   File: Mainfile.txt 
> > svn://svn/test/sub/trunc Project 
> >   File: Subfile.txt 
> > 
> > Now I make a branch and set the svn:external Propery: 
> > svn://svn/test/main/branch1 
> >   svn:external Propery: svn://svn/test/sub/branch1 sub 
> >   File: Mainfile.txt 
> > svn://svn/test/sub/branch1 Project 
> >   File: Subfile.txt 
> > 
> > 
> > On a Checkout of main Project this will result in the following file 
> structures: 
> >   mainTrunc 
> >   | Mainfile.txt 
> >   | sub 
> >   | | Subfile.txt 
> >   mainBranch 
> >   | Mainfile.txt 
> >   | sub 
> >   | | Subfile.txt 
> > 
> > 
> > If I make changes at Mainfile.txt and Subfile.txt at main in one 
> > commit with version 123. To merge these changes to the branch I have 
> > to do the following: 
> > 1. Go to mainBranch folder an merge svn://svn/test/main/trunc version 
> 123 
> > 2. Go to mainBranch/sub folder and merge svn://svn/test/sub/trunc 
> version 123 
> > All information required for the 2. merge of the externals folder is 
> > already known by the tortoise client. It knows there are files at the 
> > svn://svn/test/sub/trunc folder included at these commit and it knows 
> > these files are loyally stored at mainBranch/sub folder. 
> > 
> > 
> > 
> > With best regards, 
> >   Marcel Hesselbarth 
> > 
>
> This is a known and documented issue with externals. 
>
> The Subversion book says this on the topic: 
>  
> Perhaps most disappointingly, the working copies created via the externals 
> definition support are still disconnected from the primary working copy 
> (on 
> whose versioned directories the svn:externals property was actually set). 
> And 
> Subversion still truly operates only on nondisjoint working copies. So, 
> for 
> example, if you want to commit changes that you've made in one or more of 
> those 
> external working copies, you must run svn commit explicitly on those 
> working 
> copies—committing on the primary working copy will not recurse into any 
> external ones. 
> http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html 
>  
>
> There are reasons for not committing from externals by default. 
> For example, you might not have commit privileges for the repository 
> an externals is pointing at. If Subversion tried to commit to that 
> repository every time you make a commit that would be rather annoying. 
>
> That said, we're trying to lift some of these limitations with externals. 
> In particular, there will be a new --include-externals option for 'svn 
> commit' in Subversion 1.8. This option causes recursive commit from the 
> parent working copy as well as all externals within the working copy. 
>
> It might be possible to add this option to 'svn merge' as well, to address 
> your particular use case. You'd have to run a merge with 
> --include-externals 
> to tell Subversion "please consider the externals in my working copy 
> as part of the merge target". I think this is a valid feature request 
> and if you like you can open a new ENHANCEMENT issue (see 
> http://subversion.apache.org/reporting-issues.html for more information) 
> and name me as your bug buddy. 
>
> However it is probably not as trivial to implement as it sounds. 
> I would guess that this task would make a nice google summer of code 
> project, i.e. somebody with little or no prior experience with 
> Subversion's 
> code base would probably need about 3 months to get this featur

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

[rupert.thurner]

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: write to svn via https and ssh, svn server with one operating system user for ssh access

[rupert.thurner]

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
> > http(s) and ssh?
>
> Yes. It's in the 
> manual.http://svnbook.red-bean.com/en/1.7/svn.serverconfig.multimethod.html
oh god ... you are right. "Supporting Multiple Repository Access
Methods" is not about methods to access multiple repositories, but
about accessing the same repository via multiple methods.

>
> > 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?
>
> I think this section of the manual handles 
> that:http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn...

ah, yes  now i see it. even path based authentication can be
shared by entering it into both:
* httpd.conf
* svnserve.conf
(http://svnbook.red-bean.com/en/1.7/
svn.serverconfig.pathbasedauthz.html)

many thanks!

rupert

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

[rupert.thurner]

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: GnomeKeyring: not entering passwords

[rupert.thurner]

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 seahorse. subversion offers to be compile with --
> > with-gnome-keyring option.
>
> managing your keyring and this is tied to your login session.  What we did
> for our CollabNet binaries was write a small command line tool that uses
> the GNOME keyring API but gives you a simple command line interface.  I do
> not know why GNOME does not provide one.  I would be happy to share the
> source code if you want it.
>
> With this tool you can use the command line tool to create a keyring as
> well as unlock it.  The latter is what you would want to do when you login
> (after starting the keyring-daemon).

mark, great to hear you would be able to share this tool.

btw, the keyring-libraries are now linked to the http://opencsw.org
subversion solaris build and therefor in the upcoming opencsw
subversion-1.7.2 release:
http://sourceforge.net/apps/trac/gar/changeset/16366/csw/mgar/pkg/subversion/trunk

rupert.

GnomeKeyring: not entering passwords

[rupert.thurner]

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 line
(no gui available) after booting the operating system, or logging into
the user or starting some daemon to log into the keyring, and never
again. the goal is to have a continuous integration environment that
does not expose the passwords (easily) to the users of the server.

as i understood there are three pieces of software:
* GnomeKeyring daemon, allowing an application to store and retrieve
passwords
* GnomeKeyring manager, deprecated by
* seahorse, a gui application which allows to manage keys

would this be realistic using the GnomeKeyring daemon? i want to
include it for the http://opencsw.org subversion solaris build, and
wonder what additionally needs to be configured on the client side so
this works seamlessly.

rupert

svn log knows about svn:external

[rupert.thurner]

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, but it seems not follow
externals. i also do not know a command which easily displays all
externals contained in a working copy ... which might be easier/
quicker to find out with the new wc format?

rupert.

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

[rupert.thurner]

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 problems, or such a failure could be
expected. what makes me not so sure about this is e.g. the "editor
drive order". see also [1][2][3]. the client is v 1.6.15, and the
server, sourceforge, is 1.6.9.

[1] http://svn.haxx.se/dev/archive-2009-05/0531.shtml.
[2] http://subversion.tigris.org/issues/show_bug.cgi?id=3831, marked
as fixed
[3] http://subversion.tigris.org/issues/show_bug.cgi?id=2932

rupert

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

[rupert.thurner]

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 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 files, except via svn API",
> > see e.g.http://subclipse.tigris.org/issues/show_bug.cgi?id=761.
>
> > Alone from the number of requirements its seems pretty clear that
> > users do want this feature. But I am wondering what the correct place
> > to implement would be? Or to put it in other words, if one would
> > implement the feature into the svn command line client, where would
> > this feature go? above or below the API?
>
> Perhaps you could begin by explaining what the feature is? For the benefit of 
> those of us who are not familiar with Eclipse CVS or its "mark the local file 
> as merged" feature.

a gui tool like eclipse cvs, and also tortoise svn i think, allow a
visual compare of an incoming change. if the change is not good, one
can "mark" the local copy as the new version, and commit it over the
version in the repository.

subclipse allows this only if the local file is modified as well.

if the local file is not modified, it is epected that you _have to_
update the remote version, roll back somehow to the previous state,
and commit it. i.e. no support whatsoever by the tool. mark phippard
argues that this is the right way to do as subversion does not offer
an api call to mark the local version as changed, if i understand his
comment correctly in the subclipse issue 761.

rupert.

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

[rupert.thurner]

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 files, except via svn API",
see e.g. http://subclipse.tigris.org/issues/show_bug.cgi?id=761.

Alone from the number of requirements its seems pretty clear that
users do want this feature. But I am wondering what the correct place
to implement would be? Or to put it in other words, if one would
implement the feature into the svn command line client, where would
this feature go? above or below the API?

rupert.