no subversion.conf file after yum install on latest Fedora 20

2014-09-03 Thread James 
I am following the step by step instruction to install SVN server on latest 
Fedora 20. but after Apach and SVN are install via yum install. There is no  
/etc/httpd/conf.d/subversion.conf file found. I also put my question on 
stackoverflow site: setup SVN server on Fedora 20 issue - Stack Overflow

  
  
setup SVN server on Fedora 20 issue - Stack Overflow
I am in the process setup the SVN server on Fedora 20 by follow instruction 
from this site. The step 1 and step 2 were done successfully.   
View on stackoverflow.com Preview by Yahoo  
  
 
Does this mean the latest SVN changed it configuration file name and location?
Thanks,
James

Commit bot without password

2014-09-03 Thread Kim Gräsman 
Hello,

I'm new to the list, so forgive me if this has been discussed before.
I didn't find anything in the archives.

At my workplace, we run a simple home-cooked "gated commit" system on
top of Subversion 1.8. Users run their working copy changes through a
client program, it assembles all changes and sends them with a work
order (what to build, test and run other analysis steps for) to a
server, which runs all steps and commits on the user's behalf if they
pass.

This works really well for us, but we haven't been able to avoid
sending the user's SVN credentials together with the work order, and
this is clearly not desirable.

Is there some way to convince Subversion to commit on a user's behalf?
We'd like to designate one SVN account as the commit bot account and
let it impersonate users at will.

One suggestion that came up internally was to commit as the bot, and
then rewrite the revprops with the actual author. We're concerned
about race conditions here -- if someone manages to pull changes from
the repo between the commit and the revprops change, they'd get an
inconsistent view of the world. Since we have many build bots pulling
changes and svn sync replicating changes around the world, the risk of
this problem is compounded.

Ideas welcome, thanks!

- Kim

Re: no subversion.conf file after yum install on latest Fedora 20

2014-09-03 Thread Branko Čibej 
On 03.09.2014 20:52, James wrote:
> I am following the step by step instruction to install SVN server on
> latest Fedora 20. but after Apach and SVN are install via yum install.
> There is no  /etc/httpd/conf.d/subversion.conf file found. I also put
> my question on stackoverflow site: setup SVN server on Fedora 20 issue
> - Stack Overflow
> 
>  
>  
>   
>  
>   
>  
>   
>  
>   
>  
> setup SVN server on Fedora 20 issue - Stack Overflow
> 
>
> I am in the process setup the SVN server on Fedora 20 by follow
> instruction from this site. The step 1 and step 2 were done successfully.
>
> View on stackoverflow.com
> 
>   
> Preview by Yahoo
>
>  
>
>  
> Does this mean the latest SVN changed it configuration file name and
> location?

Binary packaging, which includes decisions about the location of HTTPd
configuration files, is up to the distribution maintainer (in the case
of Fedora, probably RedHat). The Subversion project only releases source
code, we do not release or maintain the subversion.conf file you
expected to see.

FWIW, the instructions on techadmin.net are misleading; it says there
(in step 3) that:

> Subversion creates an apache configuration file, we just need to make
> necessary changes to it..

but Subversion doesn't do any such thing.

On the other hand, the file doesn't really have to exist; you can just
create it, the example configuration looks good enough for a simple
setup. I would recommend you take a look at svnbook.org, especially the
following sections:

http://svnbook.red-bean.com/en/1.7/svn.reposadmin.html
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.html

(that is, if you haven't read The Book already).

-- Brane

Re: Commit bot without password

2014-09-03 Thread Branko Čibej 
On 03.09.2014 21:21, Kim Gräsman wrote:
> Hello,
>
> I'm new to the list, so forgive me if this has been discussed before.
> I didn't find anything in the archives.
>
> At my workplace, we run a simple home-cooked "gated commit" system on
> top of Subversion 1.8. Users run their working copy changes through a
> client program, it assembles all changes and sends them with a work
> order (what to build, test and run other analysis steps for) to a
> server, which runs all steps and commits on the user's behalf if they
> pass.
>
> This works really well for us, but we haven't been able to avoid
> sending the user's SVN credentials together with the work order, and
> this is clearly not desirable.
>
> Is there some way to convince Subversion to commit on a user's behalf?
> We'd like to designate one SVN account as the commit bot account and
> let it impersonate users at will.

The standard command-line client won't let you do that. It's possible to
write a script or program, using our bindings or API; but it's rather a
lot of work.

You could try the following trick: on the build machine, with the bot's
credentials, do this:

$ svn commit -m ... --with-revprop on-behalf-of=username

then on the server, add a pre-commit hook script that looks at the
revision properties of the transaction (svnlook propget --revprop)
that's about to be committed; and if svn:author is the bot, and the
on-behalf-of property exists, the script would replace the svn:author
value and delete the on-behalf-of property (svnadmin setrevprop).

This is just a blue-sky idea, I've never actually done that; but I don't
see a reason, offhand, why it wouldn't work.

-- Brane

Re: Commit bot without password

2014-09-03 Thread Kim Gräsman 
Hi Brane,

On Wed, Sep 3, 2014 at 9:37 PM, Branko Čibej  wrote:
> On 03.09.2014 21:21, Kim Gräsman wrote:
>>
>> Is there some way to convince Subversion to commit on a user's behalf?
>> We'd like to designate one SVN account as the commit bot account and
>> let it impersonate users at will.
>
> You could try the following trick: on the build machine, with the bot's
> credentials, do this:
>
> $ svn commit -m ... --with-revprop on-behalf-of=username
>
> then on the server, add a pre-commit hook script that looks at the
> revision properties of the transaction (svnlook propget --revprop)
> that's about to be committed; and if svn:author is the bot, and the
> on-behalf-of property exists, the script would replace the svn:author
> value and delete the on-behalf-of property (svnadmin setrevprop).
>
> This is just a blue-sky idea, I've never actually done that; but I don't
> see a reason, offhand, why it wouldn't work.

Nice idea, sounds promising!

And as for atomicity, this all happens before the commit transaction
hits the actual repo, right?

Thanks,
- Kim

Re: Commit bot without password

2014-09-03 Thread Branko Čibej 
On 03.09.2014 21:45, Kim Gräsman wrote:
> Hi Brane,
>
> On Wed, Sep 3, 2014 at 9:37 PM, Branko Čibej  wrote:
>> On 03.09.2014 21:21, Kim Gräsman wrote:
>>> Is there some way to convince Subversion to commit on a user's behalf?
>>> We'd like to designate one SVN account as the commit bot account and
>>> let it impersonate users at will.
>> You could try the following trick: on the build machine, with the bot's
>> credentials, do this:
>>
>> $ svn commit -m ... --with-revprop on-behalf-of=username
>>
>> then on the server, add a pre-commit hook script that looks at the
>> revision properties of the transaction (svnlook propget --revprop)
>> that's about to be committed; and if svn:author is the bot, and the
>> on-behalf-of property exists, the script would replace the svn:author
>> value and delete the on-behalf-of property (svnadmin setrevprop).
>>
>> This is just a blue-sky idea, I've never actually done that; but I don't
>> see a reason, offhand, why it wouldn't work.
> Nice idea, sounds promising!
>
> And as for atomicity, this all happens before the commit transaction
> hits the actual repo, right?

Yes, that's the whole point of doing this in the pre-commit hook.

-- Brane

Re: Commit bot without password

2014-09-03 Thread Kim Gräsman 
On Wed, Sep 3, 2014 at 10:08 PM, Branko Čibej  wrote:
>>> You could try the following trick: on the build machine, with the bot's
>>> credentials, do this:
>>>
>>> $ svn commit -m ... --with-revprop on-behalf-of=username
>>>
>>> then on the server, add a pre-commit hook script that looks at the
>>> revision properties of the transaction (svnlook propget --revprop)
>>> that's about to be committed; and if svn:author is the bot, and the
>>> on-behalf-of property exists, the script would replace the svn:author
>>> value and delete the on-behalf-of property (svnadmin setrevprop).
>>>
>>> This is just a blue-sky idea, I've never actually done that; but I don't
>>> see a reason, offhand, why it wouldn't work.
>> Nice idea, sounds promising!
>>
>> And as for atomicity, this all happens before the commit transaction
>> hits the actual repo, right?
>
> Yes, that's the whole point of doing this in the pre-commit hook.

Makes sense, thanks.

I'm reading about this now, but unfortunately svnadmin seems to work
on revision numbers, not transaction names, so I guess we can't use it
to set revprops. Am I missing something?

Thank you,
- Kim

Re: Commit bot without password

2014-09-03 Thread Andreas Stieger 
Hi,

On 03/09/14 21:21, Kim Gräsman wrote:
> On Wed, Sep 3, 2014 at 10:08 PM, Branko Čibej  wrote:
 You could try the following trick: on the build machine, with the bot's
 credentials, do this:

 $ svn commit -m ... --with-revprop on-behalf-of=username

 then on the server, add a pre-commit hook script that looks at the
 revision properties of the transaction (svnlook propget --revprop)
 that's about to be committed; and if svn:author is the bot, and the
 on-behalf-of property exists, the script would replace the svn:author
 value and delete the on-behalf-of property (svnadmin setrevprop).

 This is just a blue-sky idea, I've never actually done that; but I don't
 see a reason, offhand, why it wouldn't work.
>>> Nice idea, sounds promising!
>>>
>>> And as for atomicity, this all happens before the commit transaction
>>> hits the actual repo, right?
>>
>> Yes, that's the whole point of doing this in the pre-commit hook.
> 
> Makes sense, thanks.
> 
> I'm reading about this now, but unfortunately svnadmin seems to work
> on revision numbers, not transaction names, so I guess we can't use it
> to set revprops. Am I missing something?


Example for manipulating the revision properties of the incoming
transaction:
http://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/persist-ephemeral-txnprops.py?view=markup

Andreas

Re: Commit bot without password

2014-09-03 Thread Kim Gräsman 
On Wed, Sep 3, 2014 at 10:30 PM, Andreas Stieger  wrote:
>
> Example for manipulating the revision properties of the incoming
> transaction:
> http://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/persist-ephemeral-txnprops.py?view=markup

Love it, thanks!

I'll try and experiment with this tomorrow and post back.

- Kim

Re: no subversion.conf file after yum install on latest Fedora 20

2014-09-03 Thread Nico Kadel-Garcia 
On Wed, Sep 3, 2014 at 2:52 PM, James  wrote:

> I am following the step by step instruction to install SVN server on
> latest Fedora 20. but after Apach and SVN are install via yum install.
> There is no  /etc/httpd/conf.d/subversion.conf file found. I also put my
> question on stackoverflow site: setup SVN server on Fedora 20 issue -
> Stack Overflow
> 
>
>
>
>
>
>
>

What does 'yum install /etc/httpd/conf.d/subversion.conf' do? I wonder if
it got moved to another subpackage, as has been discussed for rsync and
other tools where the client package is most of it, the server setup is
only a small part and introduces a stack of dependencies that most clients
don't need.

reintegrate fails due to "claimed" incomplete merge-out

2014-09-03 Thread Jeremy Greene 
(Not ont mailing list so please cc me)

I really have tried many many things to resolve this problem — endless 
searching, commits, un-commits etc. But I’m stuck.

I think I see the issue(subdir merge of “…bitstream"), but have tried to do 
—record-only merges, merges, propedits… all to no avail.

The information below is after an un-commit of all changes back to just after 
the last merge-out from trunk to the branch (yellowstone).
Although, it’s hard to deal with the concept that after doing a merge out to 
the branch that —reintegrate should fail That just seems wrong.

Any help on this would be immensely grateful — before this marathon of svn-ing, 
I didn’t even know what mergeinfo was :) And I clearly still
don’t get something.

On trunk:
   jgreene@spi3:/home/jgreene/views/latest3$ svn merge --reintegrate 
^/z4/branches/yellowstone
  svn: Reintegrate can only be used if revisions 27743 through 28342 were 
previously
   merged from svn://svn/z4/trunk to the reintegrate source, but this 
is not the case:
z4/branches/yellowstone
Missing ranges: /z4/trunk:27879-28339

jgreene@spi3:/home/jgreene/views/latest3$

Below is the output from "svn pg svn:mergeingo -R ." at the root of the branch 
"yellowstone" workspace.
All of the merge info records go from 27743 (branch start) to 28341 EXCEPT:
z4/trunk/third_party/bitstream/mpeg:27938-28341
z4/trunk/third_party/bitstream/atsc:27938-28341
z4/trunk/third_party/bitstream:27879-28040*,28041-28341
z4/trunk/third_party/bitstream/dvb:27938-28341
z4/trunk/third_party/bitstream/common.h:27938-28341
z4/trunk/third_party/bitstream/ietf:27938-28341

FULL mergeinfo output on yellowstone branch (relating to merges out from trunk):

rapidev2_release -
z4/trunk/rapidev2_release:24018,27743-28341
fw -
z4/trunk/fw:24018,27743-28341
third_party/freetype -
z4/trunk/third_party/freetype:24018,27743-28341
Makefile -
z4/trunk/Makefile:24018,27743-28341
third_party/freeimage -
z4/trunk/third_party/freeimage:24018,27743-28341
third_party/openssl/md5.h -
z4/trunk/third_party/openssl/md5.h:24018,27743-28341
third_party/zlib -
z4/trunk/third_party/zlib:24018,27743-28341
README -
z4/trunk/README:24018,27743-28341
third_party/curl -
z4/trunk/third_party/curl:24018,27743-28341
third_party/openssl/notes -
z4/trunk/third_party/openssl/notes:24018,27743-28341
bsp/u-boot_sp2x -
z4/trunk/bsp/u-boot_sp2x:24018,27743-28341
third_party/Makefile -
z4/trunk/third_party/Makefile:24018,27743-28341
third_party/openssl/e_os2.h -
z4/trunk/third_party/openssl/e_os2.h:24018,27743-28341
third_party/Makefile.curl -
z4/trunk/third_party/Makefile.curl:24018,27743-28341
third_party/bitstream/mpeg -
z4/trunk/third_party/bitstream/mpeg:27938-28341 --
third_party/openssl -
z4/trunk/third_party/openssl:24018,27743-27878,27879-28341*
third_party/bitstream/atsc -
z4/trunk/third_party/bitstream/atsc:27938-28341 --
fpga -
z4/trunk/fpga:24018,27743-28341
. -
z4/trunk:24018,27743-27878,27879-28341*
bsp/kernel_sp2x -
z4/trunk/bsp/kernel_sp2x:24018,27743-28341
third_party/openssl/libcrypto_linux.a -
z4/trunk/third_party/openssl/libcrypto_linux.a:24018,27743-28341
third_party/bitstream -
   z4/trunk/third_party/bitstream:27879-28040*,28041-28341  --
third_party/openssl/libcrypto_win32.a -
z4/trunk/third_party/openssl/libcrypto_win32.a:24018,27743-28341
bsp -
z4/trunk/bsp:24018,27743-27878,27879-28341*
third_party/sha1 -
z4/trunk/third_party/sha1:24018,27743-28341
third_party -
z4/trunk/third_party:24018,27743-27878,27879-28341*
third_party/openssl/opensslconf.h -
z4/trunk/third_party/openssl/opensslconf.h:24018,27743-28341
rapidev2_dyn_src -
z4/trunk/rapidev2_dyn_src:24018,27743-28341
third_party/bitstream/dvb -
z4/trunk/third_party/bitstream/dvb:27938-28341  --
build -
z4/trunk/build:24018,27743-28341
rapidev2_pkgs -
z4/trunk/rapidev2_pkgs:24018,27743-28341
third_party/bitstream/common.h -
z4/trunk/third_party/bitstream/common.h:27938-28341 --
third_party/libupnp -
z4/trunk/third_party/libupnp:24018,27743-28341
third_party/libpng -
z4/trunk/third_party/libpng:24018,27743-28341
Makefile.HELP -
z4/trunk/Makefile.HELP:24018,27743-28341
third_party/openssl/libcrypto_s1.a -
z4/trunk/third_party/openssl/libcrypto_s1.a:24018,27743-28341
third_party/openssl/libcrypto_s2.a -
z4/trunk/third_party/openssl/libcrypto_s2.a:24018,27743-28341
third_party/dhcp -
z4/trunk/third_party/dhcp:24018,27743-28341
third_party/bitstream/ietf -
   z4/trunk/third_party/bitstream/ietf:27938-28341  --
third_party/mtd-utils -
z4/trunk/third_party/mtd-utils:24018,27743-28341