Re: Problems during merge

[Neels J Hofmeyr]

Hi Christoph,

it would be nice if you could provide a way to reproduce this issue. I am
aware that this can be some work, and we would highly appreciate it. :)

I too have seen some weird conflict markings and it would be nice to get a
handle on them. But we need to be able to reproduce them before we can do
that :(

I'm attaching a test script template for unix shells which creates a clean
repository and working copy for you to run svn commands in. "Simply" append
your commands after the comment that says "ACTUAL TEST".

e.g. append lines like:

 svn mkdir trunk
 echo 'this is file foo' > trunk/foo
 svn add trunk/foo

 svn commit -m "revision 1"

etc.
(Assuming that you are on a unix-like box, or that you are using cygwin)

Thanks,
~Neels


Christoph Bartoschek wrote:
> Hi, 
> 
> after a merge with conflicts I completely wrong conflict markers:
> 
> 
> === inv_merge.C =
> ...
>} else {
> <<< .working
> ===
>   _cur.sinks(to_polarity(other)).append(csol.sinks());
 .merge-right.r13821
> 
>   _cur.sinks(to_polarity(other)).append(csol.sinks());
> 
>   Time slew_limit =
> ...
> ==
> 
> In my working copy there is:
> 
> === inv_merge.C.working ==
> ...
>} else {
> 
>   _cur.sinks(to_polarity(other)).append(csol.sinks());
> 
>   Time slew_limit =
> ...
> ==
> 
> The right part only differs in an empty line:
> 
> === inv_merge.C.merge-right.r13821 ===
> ...
>} else {
>   _cur.sinks(to_polarity(other)).append(csol.sinks());
> 
>   Time slew_limit =
> ...
> ==
> 
> In the left part we have: 
> 
> === inv_merge.C.merge-left.r13820 ===
> ...
>} else {
>   _cur.sinks(to_polarity(other)).append_slice(csol.sinks().begin(),
>   csol.sinks().size());
> 
>   TimePair slew_limit =
> ...
> ==
> 
> 
> I would have expected that I see the code of the left part in the merge view 
> and not two times the code from working.
> 
> What is going wrong here?
> 
> Christoph
#!/bin/bash

## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
##  export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
##built source tree. The next line is the only line you should
##need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { ${SVNDIR}/subversion/svn/svn "$@"; }
# function svnserve() { ${SVNDIR}/subversion/svnserve/svnserve "$@"; }
# function svnadmin() { ${SVNDIR}/subversion/svnadmin/svnadmin "$@"; }

set -e

svn --version
REPOS="`pwd`/repos"
URL="file://$REPOS"
rm -rf repos wc
svnadmin create repos

# enable all revprop changes
cat > repos/hooks/pre-revprop-change <

signature.asc
Description: OpenPGP digital signature

Re: commit templates

[Neels J Hofmeyr]

Ryan Schmidt wrote:
> On Feb 8, 2010, at 15:17, Edward Peschko wrote:
> 
>> I'm looking for a clean way to use the command line client and have
>> the ability to specify a commit template when adding a comment on
>> checkin:
>>
>> BUG_ID: x
>> BUG_DESC: x
>> CHANGE_DESC:  x
>>
>> or somesuch, prefilled in my editor of choice.  I know about the
>> SVN_EDITOR workaround (setting SVN_EDITOR in such a way that a
>> template is made), but that is a horrid horrid hack and doesn't work
>> across the board on different subversion revlevels.
>>
>> So - is there a better fix for this?
> 
> As far as I know, there is not.

Edward, you could also setup a script "the other way round". e.g., to
commit, call your script, which first composes a message and then passes it
via the -F option. Something like:

#!/bin/bash
msgfile=$(tempfile)
cat /var/etc/opt/svn-commit-template > "$msgfile"
svn commit -F "$msgfile" $@

Then you must remember to call your script when you want to commit instead
of calling svn directly, and you would not have Subversion's listing of
modified files in there.

But there is currently no way to tell Subversion to use a given commit
message template. Might be a nice feature to add, as a per-user
configuration option probably.

Patches welcome! This would be the place:
trunk/subversion/svn/util.c: svn_cl__get_log_message()

~Neels



signature.asc
Description: OpenPGP digital signature

Re: Fwd: Serving internal SVN path via Apache

[Neels J Hofmeyr]

Itamar O wrote:
> Relocating the question to the correct mailing list + clarification:
> 
> I am not talking about serving multiple repositories with SVNParentPath.
> I have a single repository with the following layout:
> root (@ /var/svn/repos)
> |- projA
> |- projB
> |- ...
> 
> Each project has its own virtual host on Apache,
> with its own DNS's (e.g. www.projA.com  &
> svn.projA.com ).
> 
> I want that the svn.projA.com  virtual host will
> be directed to root/projA,
> so that users of projA SVN are not even aware of other projects.
> 
> Is this possible?

What comes to my mind is a URL rewrite in apache before it hits the DAV
(google for some beginners' tutorial for mod_rewrite). i.e. httpd-wise
redirect svn.proja.com to your.main.server/repos/sub/folder/proja.

Not sure if there will be side problems appearing. Technically, the user is
then via mod_rewrite not able to ask for URLs other than below proja/, while
the repository would still allow that if any got through.

It's hacky ;)
Not sure if there's a better way other than having dedicated repositories
per project (which is also an option).

~Neels


> 
> Thanks,
> Itamar O.
> 
> -- Forwarded message --
> From: *Itamar O* mailto:itamar...@gmail.com>>
> Date: Wed, Feb 10, 2010 at 11:00 PM
> Subject: Serving internal SVN path via Apache
> To: d...@subversion.apache.org 
> 
> 
> Is there a way to configure Apache to serve a "scoped" repository?
> e.g., if my repository root is at /var/svn/repos,
> and I have top-level project-structure,
> I want something like:
> 
>   DAV svn
>   SVNPath /var/svn/repos/projA
>   # (this doesn't work..)
>   # Maybe something like "SVNPath /var/svn/repos" & "SVNScope projA" ?
> 
> 
> Thanks,
> Itamar O.
> 



signature.asc
Description: OpenPGP digital signature

WC in file system root -- was: Re: '.' is not a working copy error and resolution (on users@)

[Neels J Hofmeyr]

(cross-posting to dev@, please continue to post only on dev@ for this thread)

Todd Gleason wrote:
> 
> 
> One of our users came across a strange error trying to commit recently
> (with a 1.6 client):
> 
>  
> 
> Action PathMime type
> 
> Command   Commit
> 
> Error   Commit failed (details follow):
> 
> Error   '.' is not a working copy
> 
> Finished!
> 
>  
> 
> On seeing this, you might think the directory he tried to commit had no
> .svn directory.  But it did.
> 
>  
> 
> After some investigation, it turned out that the parent directory (which
> was the C:\ root directory) had its own .svn directory.  He had
> accidentally done some sort of root-level checkout or move of a .svn
> directory to be under there.  I believe the result was that Subversion
> was seeing everything on that drive as not part of the working copy. 
> And indeed he couldn’t commit from anything that he believed to be a
> Subversion working copy.
> 
>  
> 
> I understand that it was correct behavior for him to get a failure
> trying to commit, but I wanted to provide this information in case it’s
> helpful to other users, and in case the developers want to change this
> sort of error to be more helpful, for example to indicate something
> about detecting a nested working copy, and including the two directories
> that conflict (the “real” WC root as well as the directory that is
> illegally nested).
> 
>  
> 
> Note that I don’t think this use case will be obsolete even in 1.7
> because I believe there will still be .svn directories directly under
> the WC root.
> 
>  
> 
> --Todd
> 
>  
> 
> 
> Please consider the environment before printing this e-mail.
> 
> The contents of this e-mail message (including any attachments) are
> confidential to and are intended to be conveyed for the use of the
> recipient to whom it is addressed only. If you receive this transmission
> in error, please notify the sender of this immediately and delete the
> message from your system. Any distribution, reproduction or use of this
> message by someone other than recipient is not authorized and may be
> unlawful.

Todd -- please don't have these mail footers when posting to Subversion
mailing lists. Having this and posting here is a contradiction in terms.
Don't expect us to assume that your footer is obsolete! And please don't say
"it's company policy", because then your company does not allow you to post
here, in which case you shouldn't ;)

About the .svn in the file system root -- technically, svn should only care
about the .svn folder at the current path. Subversion *supports* nested
working copies.

It appears there may be a bug in our "find and lock the current working
copy" code. I can reproduce that having an .svn folder in the file system
root (on a linux) causes a Segmentation Fault upon 'svn status', but *only*
when using trunk. The current 1.6 version does not error, though I did not
try to commit.

Use Subversion trunk to reproduce:
[[[
cd /tmp
svn co http://svn.apache.org/repos/asf/subversion/trunk/notes
sudo cp -a notes/tree-conflicts/.svn /
cd notes/
svn st
[prints "Segmentation fault"]

$ gdb `which svn`
GNU gdb (GDB) 7.0-debian
[...]
(gdb) run st
Starting program: /home/neels/svn/prefix/svn-current/bin/svn st
[Thread debugging using libthread_db enabled]
[New Thread 0xb764eb70 (LWP 3957)]
[Thread 0xb764eb70 (LWP 3957) exited]

Program received signal SIGSEGV, Segmentation fault.
0xb7c6ae42 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
(gdb) bt
#0  0xb7c6ae42 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#1  0xb7d36f42 in ?? () from /usr/lib/libsqlite3.so.0
#2  0xb7d01d82 in sqlite3_mutex_enter () from /usr/lib/libsqlite3.so.0
#3  0xb7d1a1a2 in ?? () from /usr/lib/libsqlite3.so.0
#4  0xb7d0c807 in ?? () from /usr/lib/libsqlite3.so.0
#5  0xb7d209ea in ?? () from /usr/lib/libsqlite3.so.0
#6  0xb7d20c34 in ?? () from /usr/lib/libsqlite3.so.0
#7  0xb7d22790 in ?? () from /usr/lib/libsqlite3.so.0
#8  0xb7d688b5 in ?? () from /usr/lib/libsqlite3.so.0
#9  0xb7d51555 in sqlite3_step () from /usr/lib/libsqlite3.so.0
#10 0xb7dce0b5 in svn_sqlite__step (got_row=0xbf800718, stmt=0x809f1b0)
at subversion/libsvn_subr/sqlite.c:197
#11 0xb7f6ca40 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c90 "/", recurse_depth=74835, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5630
#12 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c88 "/", recurse_depth=74834, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#13 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c80 "/", recurse_depth=74833, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#14 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c78 "/", recurse_depth=74832, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#

Re: Problems during merge

[Christoph Bartoschek]

Am Donnerstag, 11. Februar 2010 schrieb Neels J Hofmeyr:
> Hi Christoph,
> 
> it would be nice if you could provide a way to reproduce this issue. I am
> aware that this can be some work, and we would highly appreciate it. :)

Hi,

here is the script. When it comes to choosing the merge operation I choose 
(p).  The file dir_b/file has the wrong conflict markers.

Christoph


merge_fail.sh
Description: application/shellscript

Re: Fwd: Serving internal SVN path via Apache

[Itamar O]

Thanks Neels,
Just tried that.
When accessing svn.proja.com from a browser it worked fine.
But checkout & list on svn.proja.com failed with the message:
"/svn/projA/!svn/vcc/default path not found"

Any ideas?

On Thu, Feb 11, 2010 at 2:27 PM, Neels J Hofmeyr  wrote:

> Itamar O wrote:
> > Relocating the question to the correct mailing list + clarification:
> >
> > I am not talking about serving multiple repositories with SVNParentPath.
> > I have a single repository with the following layout:
> > root (@ /var/svn/repos)
> > |- projA
> > |- projB
> > |- ...
> >
> > Each project has its own virtual host on Apache,
> > with its own DNS's (e.g. www.projA.com  &
> > svn.projA.com ).
> >
> > I want that the svn.projA.com  virtual host will
> > be directed to root/projA,
> > so that users of projA SVN are not even aware of other projects.
> >
> > Is this possible?
>
> What comes to my mind is a URL rewrite in apache before it hits the DAV
> (google for some beginners' tutorial for mod_rewrite). i.e. httpd-wise
> redirect svn.proja.com to your.main.server/repos/sub/folder/proja.
>
> Not sure if there will be side problems appearing. Technically, the user is
> then via mod_rewrite not able to ask for URLs other than below proja/,
> while
> the repository would still allow that if any got through.
>
> It's hacky ;)
> Not sure if there's a better way other than having dedicated repositories
> per project (which is also an option).
>
> ~Neels
>
>
> >
> > Thanks,
> > Itamar O.
> >
> > -- Forwarded message --
> > From: *Itamar O* mailto:itamar...@gmail.com>>
> > Date: Wed, Feb 10, 2010 at 11:00 PM
> > Subject: Serving internal SVN path via Apache
> > To: d...@subversion.apache.org 
> >
> >
> > Is there a way to configure Apache to serve a "scoped" repository?
> > e.g., if my repository root is at /var/svn/repos,
> > and I have top-level project-structure,
> > I want something like:
> > 
> >   DAV svn
> >   SVNPath /var/svn/repos/projA
> >   # (this doesn't work..)
> >   # Maybe something like "SVNPath /var/svn/repos" & "SVNScope projA" ?
> > 
> >
> > Thanks,
> > Itamar O.
> >
>
>

Question about authz file syntax.

[Lauro Costa G. Borges]

 Hi,

 I'm using Subversion version 1.4.4 (r25188).

 I'm noticing that the authz file is not properly processed. For some
paths I have:


[/path/foo]
user1 = rw
user2 = r
@groupbar = rw
* =

All users before "* =" are forbidden on that directory, if I take "*
=" out, then, The permissions are properly applied.

My problem is, my manager wants a "default deny" ACL, so, for many of
the directories, I need to have "* = ".


* Note: I tried to put "* =" before all the other ACL's, in the end,
in the middle, doesn't seem to make difference.


 thanks in advance,

 Lauro

what does _M mean from svn status?

[Pat Farrell]

Fairly often, when I do a merge from my branch to the trunk, a handful
of files are show with a
_M indication
(that is underscore  in column 1 and an M in column 2)

What does this mean?
How do I clear it out?

Even blowing away the sandbox and checking out the whole tree does not
seem to clear it.

Thanks
Pat

Re: what does _M mean from svn status?

[Andy Levy]

On Thu, Feb 11, 2010 at 12:37, Pat Farrell  wrote:
> Fairly often, when I do a merge from my branch to the trunk, a handful
> of files are show with a
> _M indication
> (that is underscore  in column 1 and an M in column 2)
>
> What does this mean?
> How do I clear it out?
>
> Even blowing away the sandbox and checking out the whole tree does not
> seem to clear it.

M in the second column indicates that the item's properties have changed.

Having trouble finding any documentation on the underscore. Seems like
a very odd symbol to use here.

What version of Subversion are you using?

Re: Question about authz file syntax.

[Sebastian Grewe]

Hey Lauro,

Put them in a different order: Last match always decides on access
permissions.

[/path/foo]
* =
user2 = r
user1 = rw
@groupbar = rw

Something similar to that is working on my setup.

Cheers,
Sebastian

On Thu, 2010-02-11 at 15:19 -0200, Lauro Costa G. Borges wrote:
> Hi,
> 
>  I'm using Subversion version 1.4.4 (r25188).
> 
>  I'm noticing that the authz file is not properly processed. For some
> paths I have:
> 
> 
> [/path/foo]
> user1 = rw
> user2 = r
> @groupbar = rw
> * =
> 
> All users before "* =" are forbidden on that directory, if I take "*
> =" out, then, The permissions are properly applied.
> 
> My problem is, my manager wants a "default deny" ACL, so, for many of
> the directories, I need to have "* = ".
> 
> 
> * Note: I tried to put "* =" before all the other ACL's, in the end,
> in the middle, doesn't seem to make difference.
> 
> 
>  thanks in advance,
> 
>  Lauro

Re: what does _M mean from svn status?

[Pat Farrell]

Andy Levy wrote:
> M in the second column indicates that the item's properties have changed.

How do I find out what property has changed?


> Having trouble finding any documentation on the underscore. Seems like
> a very odd symbol to use here.

Its not documented in the RedBean.


> What version of Subversion are you using?

svn, version 1.6.5 (r38866)
   compiled Aug 31 2009, 18:42:02

Copyright (C) 2000-2009 CollabNet.


-- 
Pat Farrell
http://www.pfarrell.com/

Re: what does _M mean from svn status?

[Andy Levy]

On Thu, Feb 11, 2010 at 13:04, Pat Farrell  wrote:
> Andy Levy wrote:
>> M in the second column indicates that the item's properties have changed.
>
> How do I find out what property has changed?

svn diff will tell you what properties have changed and the values.

>> Having trouble finding any documentation on the underscore. Seems like
>> a very odd symbol to use here.
>
> Its not documented in the RedBean.
>
>
>> What version of Subversion are you using?
>
> svn, version 1.6.5 (r38866)
>   compiled Aug 31 2009, 18:42:02
>
> Copyright (C) 2000-2009 CollabNet.
>
>
> --
> Pat Farrell
> http://www.pfarrell.com/
>
>

Re: AW: Problems setting svn:ignore property to "*" via windows command line

[Stein Somers]

On 09/02/2010 12:51, Janosch Scharlipp wrote:

Is the runtime part of the final program, or is it available as a dll in my
os ready to be loaded on program startup?


In build lingo, that sounds: is the runtime statically linked or 
dynamically linked? It depends on how the subversion source code was 
built and packaged. I bet the configuration files/makefiles default to 
some direction (so the subject is somewhat relevant on this list) but I 
couldn't find any /MT or /MD. Either way, it's the responsibility of the 
supplier of the subversion package, like Collabnet, SlikSVN... to cook 
something that works from the source code.



Can i find out, what type of runtime is beeing used


For Windows, dependencywalker.com is great. If the runtime is 
dynamically linked, it will show something like msvcrt*.dll is used.


But if I were you, I would use the workaround suggested in this thread 
and not try to talk sense into Windows. Maybe you can fool it by passing 
a unicode * character or so.


--
Stein

Re: what does _M mean from svn status?

[Pat Farrell]

Andy Levy wrote:
> svn diff will tell you what properties have changed and the values.

OK, how do I edit it to kill the merge-info

I tried,
svn propedit svn:mergeinfo   FilterListBase.java

which brings up the properties in VI, but deleting them does not clear
them out.

svn diff FilterListBase.java

Property changes on: FilterListBase.java
___
Modified: svn:mergeinfo
   Reverse-merged
/bbook/branches/scott/fnfapp/src/java/com/fnfbook/bean/FilterListBase.java:r5623-5669,5671-5679,5801-5869,6105-6201,6932-6942,7190-7279,7387-7407,7491-7523,7683-7703
   Reverse-merged
/bbook/trunk/trunk/fnfapp/src/java/com/fnfbook/bean/FilterListBase.java:r4195-4223,5590,5823-5824
   Reverse-merged
/bbook/branches/pat/fnfapp/src/java/com/fnfbook/bean/FilterListBase.java:r5530-5544,5548-5559,5562-5588,5591-5604,5607-5616,5620-5666,5672-5679,5683-5756,5774-5776,5780-5782,5795-5813,5816-5822,5825-5829,5833-5874,5877-5924,5927-5933,5936-5983,5993-6026,6040-6055,6058-6107,6111-6136,6140-6160,6172-6175,6178-6186,6195-6218,6226-6233,6236-6252,6257-6288,6291-6303,6307-6347,6352-6365,6370-6373,6376-6382,6385-6408,6411-6430,6433-6436,6441-6453,6457-6470,6474-6486,6489-6494,6498-6504,6507-6517,6520-6558,6560-6570,6573-6576,6583-6587,6590-6596,6599-6616,6619-6632,6635-6649,6652-6664,6667-6697,6700-6730,6733-6748,6751-6778,6782-6854,6858-6911,6914-6931,6939-6953,6956-6964,6967-7044,7047-7111,7114-7119,7122-7135,7138-7145,7149-7151,7156-7186,7193-7194,7197-7218,7222-7224,7227-7294,7300-7407,7411-7422,7425-7453,7456-7474,7477-7517,7526-7538,7543-7581,7584-7608,7612-7642,7645-7650,7653-7662,7665-7689,7716-7740
   Reverse-merged
/bbook/branches/pat/trunk/fnfapp/src/java/com/fnfbook/bean/FilterListBase.java:r4196-4221,5591-5604


I want to do something, nearly anything, to make the sandbox's copy
match the repository and stop telling me that changes have been made.

Perhaps I need to do the propedit on the branch, not the trunk?

-- 
Pat Farrell
http://www.pfarrell.com/

Re: Question about authz file syntax.

[David Brodbeck]

Interesting. Did this behavior change at some point?  I'm using the syntax with 
"* =" at the end of the entry in many locations and it's always worked fine.  
svnserve 1.5.1 here.  The manual does seem to agree with your example, so I'm 
wondering if I should go through and change all of my permission entries to 
avoid future problems.


On Feb 11, 2010, at 9:51 AM, Sebastian Grewe wrote:

> Hey Lauro,
> 
> Put them in a different order: Last match always decides on access
> permissions.
> 
> [/path/foo]
> * =
> user2 = r
> user1 = rw
> @groupbar = rw
> 
> Something similar to that is working on my setup.
> 
> Cheers,
> Sebastian
> 
> On Thu, 2010-02-11 at 15:19 -0200, Lauro Costa G. Borges wrote:
>> Hi,
>> 
>> I'm using Subversion version 1.4.4 (r25188).
>> 
>> I'm noticing that the authz file is not properly processed. For some
>> paths I have:
>> 
>> 
>> [/path/foo]
>> user1 = rw
>> user2 = r
>> @groupbar = rw
>> * =
>> 
>> All users before "* =" are forbidden on that directory, if I take "*
>> =" out, then, The permissions are properly applied.
>> 
>> My problem is, my manager wants a "default deny" ACL, so, for many of
>> the directories, I need to have "* = ".
>> 
>> 
>> * Note: I tried to put "* =" before all the other ACL's, in the end,
>> in the middle, doesn't seem to make difference.
>> 
>> 
>> thanks in advance,
>> 
>> Lauro
> 
> 

-- 

David Brodbeck
System Administrator, Linguistics
University of Washington

upgrade subversion on ubunty hardy to 1.6.9

[Seth M]

I cannot upgrade SVN on my ubuntu hardy, it only will install 1.5.1 -
below is the apt-get install and the sources.list

> apt-get install subversion
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  db4.6-util subversion-tools
The following NEW packages will be installed:
  subversion
0 upgraded, 1 newly installed, 0 to remove and 32 not upgraded.
Need to get 0B/1274kB of archives.
After this operation, 4194kB of additional disk space will be used.
Selecting previously deselected package subversion.
(Reading database ... 29651 files and directories currently
installed.)
Unpacking subversion (from .../
subversion_1.5.1dfsg1-1ubuntu2~hardy2_i386.deb) ...
Setting up subversion (1.5.1dfsg1-1ubuntu2~hardy2) ...

--

> cat /etc/apt/sources.list.d/sources.list
deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu
hardy main
deb-src http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu
hardy main

deb http://ppa.launchpad.net/svn/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/svn/ppa/ubuntu hardy main

#deb http://launchpad.net/~anders-kaseorg/+archive/subversion-1.6/ubuntu
hardy main
#deb-src http://launchpad.net/~anders-kaseorg/+archive/subversion-1.6/ubuntu
hardy main

deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu
hardy universe
deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu
hardy multiverse


deb http://us.archive.ubuntu.com/ubuntu hardy universe
deb-src http://us.archive.ubuntu.com/ubuntu hardy universe

deb http://archive.turnkeylinux.org/ubuntu hardy main
deb http://archive.turnkeylinux.org/ubuntu hardy universe

deb http://archive.ubuntu.com/ubuntu hardy main
deb http://archive.ubuntu.com/ubuntu hardy universe
deb-src http://archive.ubuntu.com/ubuntu hardy universe
# deb http://archive.ubuntu.com/ubuntu hardy restricted
# deb http://archive.ubuntu.com/ubuntu hardy multiverse

deb http://archive.ubuntu.com/ubuntu hardy-updates main
deb http://archive.ubuntu.com/ubuntu hardy-updates universe
deb-src http://archive.ubuntu.com/ubuntu hardy-updates universe

# deb http://archive.ubuntu.com/ubuntu hardy-updates restricted
# deb http://archive.ubuntu.com/ubuntu hardy-updates multiverse

# deb http://archive.ubuntu.com/ubuntu hardy-backports main
# deb http://archive.ubuntu.com/ubuntu hardy-backports universe
# deb http://archive.ubuntu.com/ubuntu hardy-backports restricted
# deb http://archive.ubuntu.com/ubuntu hardy-backports multiverse

deb http://archive.canonical.com/ubuntu hardy partner
deb-src http://archive.canonical.com/ubuntu hardy partner

deb http://archive.ubuntu.com/ubuntu hardy-backports main universe
multiverse restricted

Re: Fwd: Serving internal SVN path via Apache

[Neels J Hofmeyr]

Itamar O wrote:
> Thanks Neels,
> Just tried that.
> When accessing svn.proja.com  from a browser it
> worked fine.
> But checkout & list on svn.proja.com  failed with
> the message:
> "/svn/projA/!svn/vcc/default path not found"

Heh, of course, sorry for the stupid suggestion: the client needs to know
the server's root URL. That's not because it needs access to the root of the
file tree stored *in* your repository, but because it needs access to the
proper communication interfaces, which work relative to the repository root.
Can't work.

So I guess the only way is that svn.proja.com actually points to a
repository root, which would imply that you need a separate repository per
project.

At apache.org, we have repos URLs like
http://svn.apache.org/repos/asf//
(e.g. 'httpd', 'subversion', ...)

You decide. :)

~Neels


> 
> Any ideas?
> 
> On Thu, Feb 11, 2010 at 2:27 PM, Neels J Hofmeyr  > wrote:
> 
> Itamar O wrote:
> > Relocating the question to the correct mailing list + clarification:
> >
> > I am not talking about serving multiple repositories with
> SVNParentPath.
> > I have a single repository with the following layout:
> > root (@ /var/svn/repos)
> > |- projA
> > |- projB
> > |- ...
> >
> > Each project has its own virtual host on Apache,
> > with its own DNS's (e.g. www.projA.com 
>  &
> > svn.projA.com  ).
> >
> > I want that the svn.projA.com 
>  virtual host will
> > be directed to root/projA,
> > so that users of projA SVN are not even aware of other projects.
> >
> > Is this possible?
> 
> What comes to my mind is a URL rewrite in apache before it hits the DAV
> (google for some beginners' tutorial for mod_rewrite). i.e. httpd-wise
> redirect svn.proja.com  to
> your.main.server/repos/sub/folder/proja.
> 
> Not sure if there will be side problems appearing. Technically, the
> user is
> then via mod_rewrite not able to ask for URLs other than below
> proja/, while
> the repository would still allow that if any got through.
> 
> It's hacky ;)
> Not sure if there's a better way other than having dedicated
> repositories
> per project (which is also an option).
> 
> ~Neels
> 
> 
> >
> > Thanks,
> > Itamar O.
> >
> > -- Forwarded message --
> > From: *Itamar O* mailto:itamar...@gmail.com>
> >>
> > Date: Wed, Feb 10, 2010 at 11:00 PM
> > Subject: Serving internal SVN path via Apache
> > To: d...@subversion.apache.org 
> >
> >
> >
> > Is there a way to configure Apache to serve a "scoped" repository?
> > e.g., if my repository root is at /var/svn/repos,
> > and I have top-level project-structure,
> > I want something like:
> > 
> >   DAV svn
> >   SVNPath /var/svn/repos/projA
> >   # (this doesn't work..)
> >   # Maybe something like "SVNPath /var/svn/repos" & "SVNScope projA" ?
> > 
> >
> > Thanks,
> > Itamar O.
> >
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: what does _M mean from svn status?

[Daniel Shahaf]

Pat Farrell wrote on Thu, 11 Feb 2010 at 13:04 -0500:
> Andy Levy wrote:
> > Having trouble finding any documentation on the underscore. Seems like
> > a very odd symbol to use here.
> 
> Its not documented in the RedBean.

Source inspection [1] reveals that '_' is used in the listing of files in 
a log message (i.e., the thing below the "--This line, and those below, 
will be ignored--" line in an 'svn commit' lacking -m and -F) when the 
file is neither textually modified nor added, removed, or replaced.

Is that what you were seeing?  (the subject says 'svn status', but I 
can't find an "'_'" in the 'svn st' code in trunk)

Daniel



[1] grep "'_'" subversion/svn/*.c

Re: upgrade subversion on ubunty hardy to 1.6.9

[Andy Levy]

On Thu, Feb 11, 2010 at 16:27, Seth M  wrote:
> I cannot upgrade SVN on my ubuntu hardy, it only will install 1.5.1 -
> below is the apt-get install and the sources.list
>
>> apt-get install subversion
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Suggested packages:
>  db4.6-util subversion-tools
> The following NEW packages will be installed:
>  subversion
> 0 upgraded, 1 newly installed, 0 to remove and 32 not upgraded.
> Need to get 0B/1274kB of archives.
> After this operation, 4194kB of additional disk space will be used.
> Selecting previously deselected package subversion.
> (Reading database ... 29651 files and directories currently
> installed.)
> Unpacking subversion (from .../
> subversion_1.5.1dfsg1-1ubuntu2~hardy2_i386.deb) ...
> Setting up subversion (1.5.1dfsg1-1ubuntu2~hardy2) ...

The Subversion project only officially distributes sources. Have you
asked the maintainers of the Ubuntu packages?

Re: Question about authz file syntax.

[David Brodbeck]

Actually, I take that back, the manual says it's the *first* match:
"Another important fact is that the first matching rule is the one which gets 
applied to a user."
(http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html)

On Feb 11, 2010, at 1:52 PM, David Brodbeck wrote:

> Interesting. Did this behavior change at some point?  I'm using the syntax 
> with "* =" at the end of the entry in many locations and it's always worked 
> fine.  svnserve 1.5.1 here.  The manual does seem to agree with your example, 
> so I'm wondering if I should go through and change all of my permission 
> entries to avoid future problems.
> 
> 
> On Feb 11, 2010, at 9:51 AM, Sebastian Grewe wrote:
> 
>> Hey Lauro,
>> 
>> Put them in a different order: Last match always decides on access
>> permissions.
>> 
>> [/path/foo]
>> * =
>> user2 = r
>> user1 = rw
>> @groupbar = rw
>> 
>> Something similar to that is working on my setup.
>> 
>> Cheers,
>> Sebastian
>> 
>> On Thu, 2010-02-11 at 15:19 -0200, Lauro Costa G. Borges wrote:
>>> Hi,
>>> 
>>> I'm using Subversion version 1.4.4 (r25188).
>>> 
>>> I'm noticing that the authz file is not properly processed. For some
>>> paths I have:
>>> 
>>> 
>>> [/path/foo]
>>> user1 = rw
>>> user2 = r
>>> @groupbar = rw
>>> * =
>>> 
>>> All users before "* =" are forbidden on that directory, if I take "*
>>> =" out, then, The permissions are properly applied.
>>> 
>>> My problem is, my manager wants a "default deny" ACL, so, for many of
>>> the directories, I need to have "* = ".
>>> 
>>> 
>>> * Note: I tried to put "* =" before all the other ACL's, in the end,
>>> in the middle, doesn't seem to make difference.
>>> 
>>> 
>>> thanks in advance,
>>> 
>>> Lauro
>> 
>> 
> 
> -- 
> 
> David Brodbeck
> System Administrator, Linguistics
> University of Washington
> 
> 
> 
> 

-- 

David Brodbeck
System Administrator, Linguistics
University of Washington

Re: what does _M mean from svn status?

[Pat Farrell]

Daniel Shahaf wrote:
> Source inspection [1] reveals that '_' is used in the listing of files in 
> a log message (i.e., the thing below the "--This line, and those below, 
> will be ignored--" line in an 'svn commit' lacking -m and -F) when the 
> file is neither textually modified nor added, removed, or replaced.
> 
> Is that what you were seeing?  (the subject says 'svn status', but I 
> can't find an "'_'" in the 'svn st' code in trunk)

I am not sure, I do know I see it in the commit window, below the --
comment.

Sorry for not having a perfectly reproducible problem, but that is
partially why its bugging me.

svn diff shows
Modified: svn:mergeinfo

with stuff.

Would be nice to clean this up.
Thanks
Pat

-- 
Pat Farrell
http://www.pfarrell.com/

Re: what does _M mean from svn status?

[Pat Farrell]

Daniel Shahaf wrote:
> Is that what you were seeing?  (the subject says 'svn status', but I 
> can't find an "'_'" in the 'svn st' code in trunk)

On further testing, the _ is only in the commit entries, but svn status
will show the " M"

No luck so far in clearing out the merge-info

Re: what does _M mean from svn status?

[Ryan Schmidt]

On Feb 11, 2010, at 15:28, Pat Farrell wrote:

> OK, how do I edit it to kill the merge-info

I'm not clear on why you're trying to defeat the merge tracking feature?

Re: what does _M mean from svn status?

[Pat Farrell]

Ryan Schmidt wrote:
>  Pat Farrell wrote:
>> OK, how do I edit it to kill the merge-info
> 
> I'm not clear on why you're trying to defeat the merge tracking feature?

Because:

1) I have never seen it work
2) this is the trunk, and I don't want false messages when I commit that
something has changed when it has not.

At best, the RedBean documentation on merge-tracking is vague and
misleading. It needs to be updated to something reflecting the state of
current svn releases.

-- 
Pat Farrell
http://www.pfarrell.com/

Re: upgrade subversion on ubunty hardy to 1.6.9

[Andrey Repin]

Greetings, Seth M!

> I cannot upgrade SVN on my ubuntu hardy, it only will install 1.5.1 -
> below is the apt-get install and the sources.list

>> apt-get install subversion
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Suggested packages:
>   db4.6-util subversion-tools
> The following NEW packages will be installed:
>   subversion
> 0 upgraded, 1 newly installed, 0 to remove and 32 not upgraded.
> Need to get 0B/1274kB of archives.
> After this operation, 4194kB of additional disk space will be used.
> Selecting previously deselected package subversion.
> (Reading database ... 29651 files and directories currently
> installed.)
> Unpacking subversion (from .../
> subversion_1.5.1dfsg1-1ubuntu2~hardy2_i386.deb) ...
> Setting up subversion (1.5.1dfsg1-1ubuntu2~hardy2) ...

Have you updated package list after editing sources file?
Did you added a signing key from PPA?

$ aptitude show subversion
Package: subversion
State: not installed
Version: 1.6.6dfsg-1ubuntu0maxb1~hardy1

Also, don't put custom lines to the beginning of sources.list.
Always append them to the end.

And btw...

## PPA repositories
##
## Subversion
deb http://ppa.launchpad.net/svn/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/svn/ppa/ubuntu hardy main

Source: 
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416305


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 12.02.2010, <4:17>

Sorry for my terrible english...

Re: Problems during merge

[Neels J Hofmeyr]

Christoph Bartoschek wrote:
> Am Donnerstag, 11. Februar 2010 schrieb Neels J Hofmeyr:
>> Hi Christoph,
>>
>> it would be nice if you could provide a way to reproduce this issue. I am
>> aware that this can be some work, and we would highly appreciate it. :)
> 
> Hi,
> 
> here is the script. When it comes to choosing the merge operation I choose 
> (p).  The file dir_b/file has the wrong conflict markers.
> 
> Christoph

Hi Christoph,

I found a minimal representation of your problem and dove into the code up
to the technical paper underlying the diff algorithm.
http://research.janelia.org/myers/Papers/np_diff.pdf

The smallest representation I found is attached in script form.
It merges:

(I put some '|' in there to show the length of the three respective versions)

left:
|OLD
|

right:
|NEW
|

working:
|
|NEW

(you actually had a working of:
|
|NEW
|
but the last blank line has no effect on the merge outcome)

To understand what's going on, it helps to mark the blank line; the diff
algorithm treats blank lines the same as any other lines and thus finds them
as equal. Let's see:

left:
|OLD
|foo

right:
|NEW
|foo

working:
|foo
|NEW


What happens now is that the change from 'left' to 'right' is seen as
replacing line 1 with 'NEW'. Makes sense.

But the change from 'left' to 'working' is seen as
 i) deleting line 1 and then, independently from that,
ii) appending 'NEW' *after* 'foo'.

This is a different representation of the change than we humans would expect
with blank lines instead of 'foo', but it is a correct one. Furthermore,
'foo' nicely separates the "two changes" in 'working'.

Only one part conflicts: 'Working' deletes line one, while 'right' wanted to
replace line one. You thus see a conflict:

[[[
<<< .working
===
NEW
>>> .merge-right.r3
]]]

The second change in working is appending 'NEW' (or anything else) to the
end, which does *not* conflict. So all you see is the second change merged
in without problems after the conflict.

[[[
<<< .working
===
NEW
>>> .merge-right.r3

NEW
]]]

It's all correct. Sigh.

That said, while it's technically right, this *is* quite annoying. Seeing
blank lines' matching as strong as other lines is not really desirable,
IMHO. In fact, the humanly intuitive way has less diff chunks:

[[[
<<< .working

NEW
===
NEW

>>> .merge-right.r3
]]]
(all changes accounted for in only one change chunk.)

I am wading far out of my depth when saying this, but I have a hunch that if
we were to not see blank lines as individual lines but only as tails to
non-blank lines, that we might then get more intuitive diffs.

Immediately, I get reservations. Implemented just like I said it, it would
mean that we get conflicts like this:

[[[
<<< .working
SAME THING

===
SAME THING


>>> .merge-right.r3
]]]
(trailing blank lines, when seen as tails to non-empty lines, can make
actually identical lines appear different)

So there would also have to be an algorithm that filters out
trailing-newlines-only changes back to

[[[
SAME THING

<<< .working
===

>>> .merge-right.r3
]]]


Christoph, do you have anything to add at this point? ;)

It would sure be nice to make blank lines less aggressive in diffs. I often
see diffs where, now that I think of it, the blanks "matching" all over are
messing up readability. (I just recalled to have thought this before, heh)

This is not about fixing an error, this is about choosing a different
correctness that better suits the eye...

~Neels
#!/bin/bash

## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
##  export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
##built source tree. The next line is the only line you should
##need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { ${SVNDIR}/subversion/svn/svn "$@"; }
# function svnserve() { ${SVNDIR}/subversion/svnserve/svnserve "$@"; }
# function svnadmin() { ${SVNDIR}/subversion/svnadmin/svnadmin "$@"; }

set -e

svn --version
REPOS="`pwd`/repos"
URL="file://$REPOS"
rm -rf repos wc
svnadmin create repos

# enable all revprop changes
cat > repos/hooks/pre-revprop-change < dir_a/file << EOF
OLD
 
EOF
##

svn add dir_a
svn ci -m "Adding dir_a"

svn cp  dir_a dir_b
svn ci -m "Copying"
svn up

##
cat > dir_a/file << EOF
NEW
 
EOF
##

svn ci -m "Changing dir_a/file"


##
cat > dir_b/file << EOF
 
NEW
EOF
##

cd dir_b
svn merge --accept=postpone ${URL}/dir_a/ .
cat file

svn resolve --accept=theirs-confli

Re: Serving internal SVN path via Apache

[Neels J Hofmeyr]

Sebastian Grewe wrote:
> If you have svn.proja.com available to serve the single repository
> proj-a the use  instead of Proj-a. That way that virtualhost
> only serves one repository wihout users suspecting additional repositories.

Which implies to have separate repositories per project, yes. I think the
point was that there is one large combined repository, not separate ones...

~Neels

> 
> That's how I set it up on my sites.
> 
> Cheers,
> Sebastian



signature.asc
Description: OpenPGP digital signature