Difficulty with post-commit emails

[Matthew Pounsett]

Apologies if this is handled on the list recently, but I haven't had any luck 
googling an answer.. don't see anything in the manual either.

Although I've done lots of upgrades, it's been a while since I installed a new 
subversion server completely from scratch, so I'm just now running into the 
fact that commit-email.py has been deprecated.  commit-email.rb has no useful 
documentation .. not even a basic usage summary.. so I'm trying to get 
mailer.py working.  I've run into an error I can't explain though, and I'm 
hoping someone has a pointer for me.

This is using subversion 1.7.5 and the mailer.py and python bindings that come 
with it, both installed out of ports on a FreeBSD box.

My mailer.conf file is present in the same directory as mailer.py, and is 
pretty much the default with the addition of a catch-all group at the end of 
the file:

> diff mailer.conf.example mailer.conf
24c24
< #smtp_hostname = localhost
---
> smtp_hostname = localhost
361a362,365
> [catchall]
> for_repos = /var/svn/repos/(?P[^/]*)
> to_addr   = commit-%(repo)@conundrum.com
> from_addr = svnad...@conundrum.com

I'm working with a test repository:
> ls /var/svn/repos/svn-test/
README.txt conf   davdb format hooks  locks

Subversion is running as an Apache module, so I'm expecting mailer to be run by 
the www user.  I get the following error:
> sudo -u www ./mailer.py commit svn-test 10
Traceback (most recent call last):
  File "./mailer.py", line 1435, in 
sys.argv[3:3+expected_args])
  File "/usr/local/lib/python2.7/site-packages/svn/core.py", line 307, in 
run_app
return func(application_pool, *args, **kw)
  File "./mailer.py", line 100, in main
repos = Repository(repos_dir, revision, pool)
  File "./mailer.py", line 1116, in __init__
self.repos_ptr = svn.repos.open(repos_dir, pool)
  File "/usr/local/lib/python2.7/site-packages/libsvn/repos.py", line 212, in 
svn_repos_open
return _repos.svn_repos_open(*args)
svn.core.SubversionException: 2 - Can't open file 'svn-test/format': No such 
file or directory


The file svn-test/format is clearly present.  This isn't just environment.. I 
get the same error passed back when mailer.py is run by a post-commit script.  
Is there something else here I'm missing?

Re: Difficulty with post-commit emails

[Matthew Pounsett]

On 2012/07/09, at 16:03, Daniel Shahaf wrote:

> Please confirm that $PWD was '/var/svn/repos' when you ran this command.

I did eventually figure this out yesterday.  Thanks for the response though!
I was passing the name of the repository, rather than the path to the 
repository.  I guess I assumed mailer would work it out somehow from the path 
in for_repos, which seems sortof silly now that I look back at it. :)

Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

[Matthew Pounsett]

On 2012/07/11, at 01:13, Jason Heeris wrote:

> The problem is this: it doesn't seem to work on files with the '[' or ']' 
> characters in their name. Ignoring VisualSVN's GUI for now, I've tried going 
> one step further and editing the "authz-windows" file by hand and I just 
> can't seem to get it to work. I've tried variations like:

I note by your examples that you're using a unix filesystem (as opposed to 
Windows).  I would be a little surprised if this worked there, since the square 
brackets are normally used by unix shells as glob metacharacters, similarly to 
* and ?. 

For example, 'tmp[123].txt' is a glob pattern to match tmp1.txt, tmp2.txt and 
tmp3.txt.

Sorry, I'm not sure how to help you make this work.  If you can avoid using 
those characters in file names, please do so at all costs.  A good rule of 
thumb is that if you can't create the file from a command line in a shell 
without escaping characters, then don't use those characters.  


> It's also worth pointing out that some paths have the "#" character in them. 
> What do I do when I get to those?

This is commonly comment character.  It's possible to create a file with this 
character in it, but personally I'd avoid it.  It's possible you could escape 
it like so: "tmp\#1.txt", but I'm not confident that will work.  If svn can't 
deal with this one you might have a case for it being a bug, since it is 
technically a legal file name.

Cleaning out an old subscriber

[Matthew Pounsett]

Hi List Admins.  Sorry, but I couldn't find a list admin address on the web 
site for this, so I'm sending it to the list itself.

I'm sure others have seen this too, but any time I post to the list I'm getting 
a bounce from world.deshaw.com.  Could an admin track down this subscriber and 
remove them from the list?

Thanks,
   Matt Pounsett


Begin forwarded message:

> From: Postmaster 
> Subject: Important: message being returned.
> Date: July 11, 2012 11:02:20 EDT
> To: m...@conundrum.com
> Reply-To: nob...@world.deshaw.com
> 
> Thank you for your inquiry.  Justin Vallon is no longer with the firm.  For 
> immediate assistance, please contact Reception at +1-212-478-.
> 
> Sincerely,
> The D. E. Shaw Group
> 
> 
> -- 8< --- CUT HERE ------ CUT HERE --- >8 --
> 
>  From:Matthew Pounsett 
>  To:  Jason Heeris 
>  cc:  users@subversion.apache.org
>  Subject: Re: Square brackets in file names and authz (in VisualSVN 2.5.5)
> 
> 
>  On 2012/07/11, at 01:13, Jason Heeris wrote:
> 
>> The problem is this: it doesn't seem to work on files with the '[' or ']' 
>> characters in their name. Ignoring VisualSVN's GUI for now, I've tried going 
>> one step further and editing the "authz-windows" file by hand and I just 
>> can't seem to get it to work. I've tried variations like:
> 
>  I note by your examples that you're using a unix filesystem (as opposed to 
> Windows).  I would be a little surprised if this worked there, since the 
> square brackets are normally used by unix shells as glob metacharacters, 
> similarly to * and ?. 
> 
>  For example, 'tmp[123].txt' is a glob pattern to match tmp1.txt, tmp2.txt 
> and tmp3.txt.
> 
>  Sorry, I'm not sure how to help you make this work.  If you can avoid using 
> those characters in file names, please do so at all costs.  A good rule of 
> thumb is that if you can't create the file from a command line in a shell 
> without escaping characters, then don't use those characters.  
> 
> 
>> It's also worth pointing out that some paths have the "#" character in them. 
>> What do I do when I get to those?
> 
>  This is commonly comment character.  It's possible to create a file with 
> this character in it, but personally I'd avoid it.  It's possible you could 
> escape it like so: "tmp\#1.txt", but I'm not confident that will work.  If 
> svn can't deal with this one you might have a case for it being a bug, since 
> it is technically a legal file name.
> 
> 
> 
> 

Re: Cleaning out an old subscriber

[Matthew Pounsett]

On 2012/07/11, at 12:13, Bob Archer wrote:

> If you send me the full email that is causing the bounce I can unsubscribe 
> it. I haven't seen the bounces.

Sorry, a regular subscriber can't help you there.  I have no idea what 
subscribed email address leads to that destination, and can't know without 
access to the full subscriber list.

As far as I can tell, all it takes is an email to the 
users@subversion.apache.org list to generate a bounce.

Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

[Matthew Pounsett]

On 2012/07/11, at 20:20, David Brodbeck wrote:

> On Wed, Jul 11, 2012 at 8:01 AM, Matthew Pounsett  wrote:
>> I note by your examples that you're using a unix filesystem (as opposed to 
>> Windows).  I would be a little surprised if this worked there, since the 
>> square brackets are normally used by unix shells as glob metacharacters, 
>> similarly to * and ?.
> 
> Just because they're used as shell metacharacters doesn't mean they
> aren't legal in filenames:

Right, but anything using simple methods of globbing may not react well to 
their use, as the OP seems to have discovered.  I didn't say you couldn't force 
the files to be created, just that I'd be a little surprised if those 
characters worked in authz configs.

That said.. it turns out the OP is on Windows after all, and I was just fooled 
by the non-windows notation for the file names.  I'm no authority on what is or 
isn't possible on NTFS since I haven't touched it in a good 10+ years so it's 
likely none of what I had to say applies to his problem.

> 
>>> It's also worth pointing out that some paths have the "#" character in 
>>> them. What do I do when I get to those?
>> 
>> This is commonly comment character.  It's possible to create a file with 
>> this character in it, but personally I'd avoid it.  It's possible you could 
>> escape it like so: "tmp\#1.txt", but I'm not confident that will work.  If 
>> svn can't deal with this one you might have a case for it being a bug, since 
>> it is technically a legal file name.
> 
> emacs uses files starting and ending in "#" extensively for autosave
> recovery data, FWIW.

Again, didn't say it wasn't possible.. just that it might not be well advised.

Unexpected conflicts merging updates from trunk to a branch

[Matthew Pounsett]

I've been running into unexpected tree conflicts when updating branches from 
the trunk, after reintegrating to the trunk where and file adds or removes were 
involved in the reintegrate.  I expect I'm doing something wrong here, but I 
haven't been able to figure out what.  Can someone point me in the right 
direction?   Here's a simple example that demonstrates my issue.

In this case my server is 1.7.5 and my client is the MacOS client 1.6.17.

~/Development/svn-test > svn update
At revision 30.

~/Development/svn-test > cd branches/

~/Development/svn-test/branches > svn cp ^/trunk mybranch
Checked out revision 30.
A mybranch

~/Development/svn-test/branches > svn commit -m "created mybranch"
Adding branches/mybranch

Committed revision 31.

~/Development/svn-test/branches > cd mybranch/

~/Development/svn-test/branches/mybranch > touch foo

~/Development/svn-test/branches/mybranch > svn add foo
A foo

~/Development/svn-test/branches/mybranch > svn commit -m "added file foo"
Adding mybranch/foo
Transmitting file data .
Committed revision 32.

# Not necessary.. just being paranoid for demonstration purposes.
~/Development/svn-test/branches/mybranch > svn merge ^/trunk

~/Development/svn-test/branches/mybranch > cd ../../trunk/

~/Development/svn-test/trunk > svn merge --reintegrate ^/branches/mybranch
--- Merging differences between repository URLs into '.':
Afoo

# Again, probably not necessary.
~/Development/svn-test/trunk > svn update
At revision 32.

~/Development/svn-test/trunk > svn commit -m "reintegrated mybranch"
Sendingtrunk
Adding trunk/foo

Committed revision 33.

~/Development/svn-test/trunk > cd ../branches/mybranch/

~/Development/svn-test/branches/mybranch > svn update
At revision 33.

# With this merge I expect to pick up any changes that are the results of
# any reintegration from other branches, but not changes I reintegrated from 
# this branch already.
~/Development/svn-test/branches/mybranch > svn merge ^/trunk
--- Merging r33 into '.':
   C foo
Summary of conflicts:
  Tree conflicts: 1

~/Development/svn-test/branches/mybranch > svn status
 M  .
  C foo
  >   local add, incoming add upon merge

Re: Unexpected conflicts merging updates from trunk to a branch

[Matthew Pounsett]

On 2013/02/07, at 10:09, Stefan Sperling wrote:

> On Thu, Feb 07, 2013 at 09:19:47AM -0500, Matthew Pounsett wrote:
>> 
>> I've been running into unexpected tree conflicts when updating branches from 
>> the trunk, after reintegrating to the trunk where and file adds or removes 
>> were involved in the reintegrate.  I expect I'm doing something wrong here, 
>> but I haven't been able to figure out what.  Can someone point me in the 
>> right direction?   Here's a simple example that demonstrates my issue.
> 
> You cannot keep using the as-is branch after it has been reintegrated.

Ah, of course.  Thanks very much for the references.. I'll go have another 
re-read.

> 
> Please review the entire "Reintegrating a Branch" section again:
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
> and also see the "Keeping a Reintegrated Branch Alive", which discusses
> the problem in detail:
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
> 
> This will be much easier in 1.8, see:
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
> 

Re: Merge, reintegrate, and merge with tree conflicts

[Matthew Pounsett]

On 2013/02/22, at 14:15, James Hanley wrote:

> We are seeing merge tree conflicts where I believe svn is not working
> as expected.  I'm not entirely sure if this is due to a lack of
> understanding for proper use on our part, but it was my understanding
> that reintegrate was to be used when pulling changes from a branch and
> pushing them into the copied from branch.

I asked about this a couple of weeks ago[1] as well.  The explanation I got[2] 
was that once you've done a --reintegrate, the source of that merge is a dead 
branch, and cannot be used again.  You can demonstrate this much simpler this 
way:

cd branches
svn cp ^/trunk ./mybranch
cd mybranch
mkdir foo
svn add foo
svn commit -m "added foo to mybranch"
cd ../../trunk
svn merge --reintegrate ^/branches/mybranch
cd ../branches/mybranch
svn merge ^/trunk

As soon as the --reintegrate is done, ^/branches/mybranch is dead.


[1] 

[2]