You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2006/02/12 18:46:12 UTC
[PATCH] To automate the svnsshcheck
Hi All,
The attached patch automates the svnsshcheck and make makes '100%' of
testsuite as with other access mechanisms.
With regards
Kamesh Jayachandran
[[[
Automate the svnsshcheck and make sure ssh tunnel understands
--user = jconstant/jrandom accordingly.
Patch by: Kamesh Jayachandran <ka...@collab.net>
* Makefile.in
(createtestsshsetup): Automatically creates public/private keys
for jconstant/jrandom adds localhost to known_hosts.
(restoresshsetup): Restores the original configuration upon test
completion.
(svnsshcheck): depends on 'createtestsshsetup' and 'restoresshsetup'
* subversion/tests/cmdline/README
Small doc on this svnsshcheck automation.
* subversion/tests/cmdline/svntest/main.py
(setup_tunnel): Sets up the SVN_SSH environment variable with
'ssh -p port -i /path/to/jconstant_or_jrandom_private_key
[based on --username argument] hostname[localhost]
(run_svn): calls setup_tunnel
(run_svnsync): calls setup_tunnel
]]]
Re: [PATCH] To automate the svnsshcheck
Posted by Kamesh Jayachandran <ka...@collab.net>.
kfogel@collab.net wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
>> The proposed solution properly undoes test '.ssh' setup upon test
>> completion.
>>
>> So I could not see any mess here.
>> May be abrupt termination of 'make svnsshcheck'(^C or make exiting
>> with errors) before 'restoresshsetup' could cause redundant entries in
>> the .ssh/authorized_keys file, in the case I can document this
>> behaviour and ask people to run 'make restoresshsetup' to cleanup this
>> trivial redundancy.
>>
>> Let me know if you meant something else.
>>
>
> Even assuming the tests run to completion (which, as you note, is not
> a safe assumption), the tests still take a long time and a person
> might use their .ssh directory during that time. I often do, in fact.
>
>
The patch tries to append the newly created pub keys(jconstant/jrandom)
to ~/.ssh/authorized_keys file so the existing ssh key configuration
still holds.
If you mean that some hand edit/some other tool changes
~/.ssh/authorized_keys file while the tests are running and 'undo' just
ignore this changes.
Then could modify my 'undo' to be more intelligent by removing what
exactly has been written by the auto setup.
Let me know if I miss something.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Kamesh Jayachandran <ka...@collab.net>.
Would investigate this option.
But it needs my [PATCH] for 1942 to be checked in which received -1 from
Eric Gillespie.
I had addressed the concern raised by Eric Gillespie did not hear
anything after that from the community.
With regards
Kamesh Jayachandran
Brian Behlendorf wrote:
> On Thu, 16 Feb 2006, Kamesh Jayachandran wrote:
>> Brian Behlendorf wrote:
>>>
>>> Could you avoid the need to muck with ~/.ssh/ by using a different
>>> file denoted by the AuthorizedKeysFile keyword for sshd?
>>>
>>> Brian
>>>
>> Do you mean to run the separate instance of sshd with this
>> customization for this test?
>
> Yes. Invoking sshd with a controlled and known config file might also
> avoid other surprises, such as someone who has configured their system
> sshd to deny key-based auth.
>
> Brian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 16 Feb 2006, Kamesh Jayachandran wrote:
> Brian Behlendorf wrote:
>>
>> Could you avoid the need to muck with ~/.ssh/ by using a different file
>> denoted by the AuthorizedKeysFile keyword for sshd?
>>
>> Brian
>>
> Do you mean to run the separate instance of sshd with this customization for
> this test?
Yes. Invoking sshd with a controlled and known config file might also
avoid other surprises, such as someone who has configured their system
sshd to deny key-based auth.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Kamesh Jayachandran <ka...@collab.net>.
Brian Behlendorf wrote:
> On Wed, 15 Feb 2006, kfogel@collab.net wrote:
>> Kamesh Jayachandran <ka...@collab.net> writes:
>>> The proposed solution properly undoes test '.ssh' setup upon test
>>> completion.
>>>
>>> So I could not see any mess here.
>>> May be abrupt termination of 'make svnsshcheck'(^C or make exiting
>>> with errors) before 'restoresshsetup' could cause redundant entries in
>>> the .ssh/authorized_keys file, in the case I can document this
>>> behaviour and ask people to run 'make restoresshsetup' to cleanup this
>>> trivial redundancy.
>>>
>>> Let me know if you meant something else.
>>
>> Even assuming the tests run to completion (which, as you note, is not
>> a safe assumption), the tests still take a long time and a person
>> might use their .ssh directory during that time. I often do, in fact.
>
> Could you avoid the need to muck with ~/.ssh/ by using a different
> file denoted by the AuthorizedKeysFile keyword for sshd?
>
> Brian
>
Do you mean to run the separate instance of sshd with this customization
for this test?
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Brian Behlendorf <br...@collab.net>.
On Wed, 15 Feb 2006, kfogel@collab.net wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>> The proposed solution properly undoes test '.ssh' setup upon test
>> completion.
>>
>> So I could not see any mess here.
>> May be abrupt termination of 'make svnsshcheck'(^C or make exiting
>> with errors) before 'restoresshsetup' could cause redundant entries in
>> the .ssh/authorized_keys file, in the case I can document this
>> behaviour and ask people to run 'make restoresshsetup' to cleanup this
>> trivial redundancy.
>>
>> Let me know if you meant something else.
>
> Even assuming the tests run to completion (which, as you note, is not
> a safe assumption), the tests still take a long time and a person
> might use their .ssh directory during that time. I often do, in fact.
Could you avoid the need to muck with ~/.ssh/ by using a
different file denoted by the AuthorizedKeysFile keyword for sshd?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by kf...@collab.net.
Kamesh Jayachandran <ka...@collab.net> writes:
> The proposed solution properly undoes test '.ssh' setup upon test
> completion.
>
> So I could not see any mess here.
> May be abrupt termination of 'make svnsshcheck'(^C or make exiting
> with errors) before 'restoresshsetup' could cause redundant entries in
> the .ssh/authorized_keys file, in the case I can document this
> behaviour and ask people to run 'make restoresshsetup' to cleanup this
> trivial redundancy.
>
> Let me know if you meant something else.
Even assuming the tests run to completion (which, as you note, is not
a safe assumption), the tests still take a long time and a person
might use their .ssh directory during that time. I often do, in fact.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/15/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> It's not just a matter of it cleaning up after itself, I'm
> uncomfortable having it mess around in .ssh at all. I'd really prefer
> that people who want to run the svn+ssh:// tests just manually set
> that stuff up, so they are aware that it's happening.
+1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DAV unlock problem.
Posted by Peter Lundblad <pe...@famlundblad.se>.
Peter Lundblad writes:
> Justin Erenkrantz writes:
> > On 2/15/06, Alexander Kitaev <al...@tmate.org> wrote:
> > No, it's svn_client_unlock that is fetching the locks well before
> > ra_dav's unlock function is executed (see line 501). I'm not real
> > clear why we *need* to fetch the tokens from the server if we have it
> > already in the WC though.
> >
>
> That's a bug in the client code whitch was introduced late in the
> locking branch. XFail test committed in r18691. Working on the fix.
>
Fixed in r18694. Will nominate for backport to 1.3.x tomorrow.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DAV unlock problem.
Posted by Peter Lundblad <pe...@famlundblad.se>.
Justin Erenkrantz writes:
> On 2/15/06, Alexander Kitaev <al...@tmate.org> wrote:
> > First:
> >
> > PROPFIND to get lock-token (lockdiscovery) is always sent on "svn unlock",
> > independently on whether there is lock token in the working copy or not. As
> > PROPFIND is sent just before "UNLOCK" I suppose that "token" passed
> > toshim_svn_ra_dav_ _unlock is always NULL.
>
> No, it's svn_client_unlock that is fetching the locks well before
> ra_dav's unlock function is executed (see line 501). I'm not real
> clear why we *need* to fetch the tokens from the server if we have it
> already in the WC though.
>
That's a bug in the client code whitch was introduced late in the
locking branch. XFail test committed in r18691. Working on the fix.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: DAV unlock problem.
Posted by Alexander Kitaev <al...@tmate.org>.
Hello Justin,
Here what I have at the working copy:
C:\test\svn\wc\lock\trunk>svn st -vu .
T 2 2 first file.txt
1 1 first .
Status against revision: 2
file.txt was first locked by user "first" and then lock was stolen by the
user "second".
Lock-token in the working copy is:
lock-token="opaquelocktoken:1aec487f-520d-0410-9ab9-d21134449303"
Then I'm trying to do unlock (with subversion 1.3.0 command line client) and
get the following:
Full ethereal log: http://tmate.org/svn/svn-unlock.pcap
====================================
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/vcc/default HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/bln/2 HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.0
<?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><prop>
<lockdiscovery xmlns="DAV:"/> </prop></propfind>
HTTP/1.1 207 Multi-Status (text/xml)
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
<D:response>
<D:href>/svn/repos/lock/trunk/file.txt</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery><D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:47c74381-520d-0410-8f02-e6b196271972</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.0
Host: 80.188.80.120
User-Agent: SVN/1.3.0 (r17949) neon/0.25.4
Lock-Token: <opaquelocktoken:47c74381-520d-0410-8f02-e6b196271972>
Via: 1.1 localhost:3128 (squid/2.5.STABLE12-NT)
X-Forwarded-For: 127.0.0.1
Cache-Control: max-age=259200
Connection: keep-alive
HTTP/1.1 401 Authorization Required (text/html)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.0
HTTP/1.1 403 Forbidden (text/html)
===================================
Please note the following:
1. Lock token sent differs from the one stored in the working copy.
2. Server sends 403 HTTP response only because credentials of the user are
different from those of the lock owner, and server doesn't report that the
lock is stolen.
When I'm using JavaSVN, that uses lock-token from the working copy, I get
the following log:
Full ethereal log: http://tmate.org/svn/javasvn-unlock.pcap
===================================
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/vcc/default HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/bln/2 HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.1
HTTP/1.1 401 Authorization Required (text/html)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.1
Host: 80.188.80.120:80
User-Agent: JavaSVN (http://tmate.org/svn/)
Keep-Alive: Connection: TE, Keep-Alive
TE: trailers Authorization:
Basic Zmlyc3Q6Zmlyc3Q=
Content-Length: 0
Accept-Encoding: gzip
Content-Type: text/xml; charset="utf-8"
Lock-Token: <opaquelocktoken:1aec487f-520d-0410-9ab9-d21134449303>
HTTP/1.1 400 Bad Request (text/html)
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
===================================
Please, note:
1. Lock token from the working copy is used.
2. Server response doesn't contain error message.
3. Apache error log contains the following line:
(2)No such file or directory: The locktoken specified in the "Lock-Token:"
header did not specify one of this resource's locktoken(s). [400, #0]
The problem that affects end-user is that in both cases error message is not
relevant and doesn't explain why the file cannot be unlocked.
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: justin.erenkrantz@gmail.com
> [mailto:justin.erenkrantz@gmail.com] On Behalf Of Justin Erenkrantz
> Sent: Thursday, February 16, 2006 18:39
> To: alex@tmate.org
> Cc: SVN Dev
> Subject: Re: DAV unlock problem.
>
> On 2/15/06, Alexander Kitaev <al...@tmate.org> wrote:
> > First:
> >
> > PROPFIND to get lock-token (lockdiscovery) is always sent on "svn
> > unlock", independently on whether there is lock token in
> the working
> > copy or not. As PROPFIND is sent just before "UNLOCK" I
> suppose that
> > "token" passed toshim_svn_ra_dav_ _unlock is always NULL.
>
> No, it's svn_client_unlock that is fetching the locks well
> before ra_dav's unlock function is executed (see line 501).
> I'm not real clear why we *need* to fetch the tokens from the
> server if we have it already in the WC though.
>
> > Second:
> >
> > Sending UNLOCK with obsolete lock-token causes server to
> respond with
> > 400 HTTP status, without any meaningful error message inside.
>
> Are you sure about this? Here's the steps I used:
>
> justin@machine1% svn lock htpasswd.c
> 'htpasswd.c' locked by user 'justin'
> bob@machine2% svn lock htpasswd.c
> svn: Lock request failed: 423 Locked (http://...)
> bob@machine2% svn lock --force htpasswd.c 'htpasswd.c' locked
> by user 'bob'.
> justin@machine1% svn unlock htpasswd.c
> svn: Unlock request failed: 403 Forbidden (http://...)
>
> I confirmed the network traces to ensure that the UNLOCK is
> being sent correctly by the client and that it isn't getting
> 400 back. Client is trunk with ra_dav and neon 0.24.7.
> Server is 1.3.0 with httpd 2.2.0.
> -- justin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DAV unlock problem.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/15/06, Alexander Kitaev <al...@tmate.org> wrote:
> First:
>
> PROPFIND to get lock-token (lockdiscovery) is always sent on "svn unlock",
> independently on whether there is lock token in the working copy or not. As
> PROPFIND is sent just before "UNLOCK" I suppose that "token" passed
> toshim_svn_ra_dav_ _unlock is always NULL.
No, it's svn_client_unlock that is fetching the locks well before
ra_dav's unlock function is executed (see line 501). I'm not real
clear why we *need* to fetch the tokens from the server if we have it
already in the WC though.
> Second:
>
> Sending UNLOCK with obsolete lock-token causes server to respond with 400
> HTTP status, without any meaningful error message inside.
Are you sure about this? Here's the steps I used:
justin@machine1% svn lock htpasswd.c
'htpasswd.c' locked by user 'justin'
bob@machine2% svn lock htpasswd.c
svn: Lock request failed: 423 Locked (http://...)
bob@machine2% svn lock --force htpasswd.c
'htpasswd.c' locked by user 'bob'.
justin@machine1% svn unlock htpasswd.c
svn: Unlock request failed: 403 Forbidden (http://...)
I confirmed the network traces to ensure that the UNLOCK is being sent
correctly by the client and that it isn't getting 400 back. Client is
trunk with ra_dav and neon 0.24.7. Server is 1.3.0 with httpd 2.2.0.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Kamesh Jayachandran <ka...@collab.net>.
Philip Martin wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>
>> It's not just a matter of it cleaning up after itself, I'm
>> uncomfortable having it mess around in .ssh at all.
>>
>
> Me too. Also, it probably won't work if someone tries to run multiple
> instances of the testsuite simultaneously.
>
>
Made the following corrections to the patch.
1)Undone the changes made to svnsshcheck target.
2)Updated the doc to call the key configuration/cleanup targets explicitly.
3)Modified the undoing of changes to authorized_keys file selectively
rather than 'mv authorized_keys.pristine authorized_keys'
4)Renamed the targets to mean what they do.
5)destroytestsshsetup target undoes the current build area's current
testsuite key configuration only.
6)destroytestsshsetup_bruteforce target undoes the current build area's
all past testsuite key configurations.
With regards
Kamesh Jayachandran
[[[
Automate the svnsshcheck and make sure ssh tunnel understands
--user = jconstant/jrandom accordingly.
Patch by: Kamesh Jayachandran <ka...@collab.net>
* Makefile.in
(createtestsshsetup): Creates public/private keys
for jconstant/jrandom, sets up key based authentication stuff working
the adds localhost to known_hosts.
(destroytestsshsetup): Undoes key based authentication setup upon test
completion for the current testsuite execution and current build area.
(destroytestsshsetup_bruteforce): Could be used to undo the key setups
done by the test system in earlier invocations for current build area
in a brute force way.
* subversion/tests/cmdline/README
Small doc on this svn+ssh test key configuration automation.
* subversion/tests/cmdline/svntest/main.py
(setup_tunnel): Sets up the SVN_SSH environment variable with
'ssh -p port -i /path/to/jconstant_or_jrandom_private_key
[based on --username argument] hostname[localhost]
(run_svn): calls setup_tunnel
(run_svnsync): calls setup_tunnel
]]]
Re: DAV unlock problem.
Posted by kf...@collab.net.
"Alexander Kitaev" <al...@tmate.org> writes:
> I've found two related problems with "svn unlock" over DAV (Subversion
> 1.3.0, both server and client are on Windows XP):
Alex, please see
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
about keeping new topics out of existing threads, thanks.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
DAV unlock problem.
Posted by Alexander Kitaev <al...@tmate.org>.
Hello All,
I've found two related problems with "svn unlock" over DAV (Subversion
1.3.0, both server and client are on Windows XP):
First:
PROPFIND to get lock-token (lockdiscovery) is always sent on "svn unlock",
independently on whether there is lock token in the working copy or not. As
PROPFIND is sent just before "UNLOCK" I suppose that "token" passed
toshim_svn_ra_dav_ _unlock is always NULL.
Second:
Sending UNLOCK with obsolete lock-token causes server to respond with 400
HTTP status, without any meaningful error message inside.
Should I submit these to the issues tracker?
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: Wednesday, February 15, 2006 10:58 PM
> To: Garrett Rooney
> Cc: Kamesh Jayachandran; SVN Dev
> Subject: Re: [PATCH] To automate the svnsshcheck
>
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > It's not just a matter of it cleaning up after itself, I'm
> > uncomfortable having it mess around in .ssh at all.
>
> Me too. Also, it probably won't work if someone tries to run
> multiple instances of the testsuite simultaneously.
>
> --
> Philip Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> It's not just a matter of it cleaning up after itself, I'm
> uncomfortable having it mess around in .ssh at all.
Me too. Also, it probably won't work if someone tries to run multiple
instances of the testsuite simultaneously.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/15/06, Kamesh Jayachandran <ka...@collab.net> wrote:
> Hi Garrett,
> The proposed solution properly undoes test '.ssh' setup upon test
> completion.
>
> So I could not see any mess here.
> May be abrupt termination of 'make svnsshcheck'(^C or make exiting with
> errors) before 'restoresshsetup' could cause redundant entries in the
> .ssh/authorized_keys file, in the case I can document this behaviour and
> ask people to run 'make restoresshsetup' to cleanup this trivial redundancy.
>
> Let me know if you meant something else.
It's not just a matter of it cleaning up after itself, I'm
uncomfortable having it mess around in .ssh at all. I'd really prefer
that people who want to run the svn+ssh:// tests just manually set
that stuff up, so they are aware that it's happening.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Garrett,
The proposed solution properly undoes test '.ssh' setup upon test
completion.
So I could not see any mess here.
May be abrupt termination of 'make svnsshcheck'(^C or make exiting with
errors) before 'restoresshsetup' could cause redundant entries in the
.ssh/authorized_keys file, in the case I can document this behaviour and
ask people to run 'make restoresshsetup' to cleanup this trivial redundancy.
Let me know if you meant something else.
With regards
Kamesh Jayachandran
Garrett Rooney wrote:
> On 2/12/06, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>> Hi All,
>> The attached patch automates the svnsshcheck and make makes '100%' of
>> testsuite as with other access mechanisms.
>>
>
> I'm not all that comfortable having our build system mess with
> someone's .ssh directory. Perhaps it would get us part way to solving
> this problem if we simply had better instructions on what you need to
> do to get the tests to run over ssh.
>
> -garrett
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] To automate the svnsshcheck
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/12/06, Kamesh Jayachandran <ka...@collab.net> wrote:
> Hi All,
> The attached patch automates the svnsshcheck and make makes '100%' of
> testsuite as with other access mechanisms.
I'm not all that comfortable having our build system mess with
someone's .ssh directory. Perhaps it would get us part way to solving
this problem if we simply had better instructions on what you need to
do to get the tests to run over ssh.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org