Re: Unexpected Externals behaviour in working copy
On 12 March 2010 11:28, David Aldrich wrote: > Hi > > I haven't had a reply to this question of mine yet. So I would like to > rephrase it: > > Is it true that if I delete an external relating to a folder or file then svn > will not automatically delete that folder/file from my local working copy? Hi David, when I analysed externals in 1.6 about a year ago, that is what I found. I consider it a bug. It's like this: Dir externals are not removed from your WC, but they are "forgotten" alright. If you remove the external prop, remove the external folder and svn up, it is still gone. File externals are not even capable of being forgotten! If you remove the prop, remove the file, and then update, the damn thing *comes back*! That's a stupid bug, no-one has gotten around to fix it yet. You need a new checkout of the parent folder. I attached a script that illustrates externals behaviour. I tested with 1.6.x. ~Neels > > This seems to be related to Subversion issue #3351 (although that issue only > relates to file externals, not folder externals). > > It is seems that a fresh check out is required. Or is it ok to delete the > 'external' folder/file in my wc using an operating system delete operation? > > Best regards > > David > > > From: David Aldrich [david.aldr...@eu.nec.com] > Sent: 11 March 2010 16:11 > To: users@subversion.apache.org > Subject: Unexpected Externals behaviour in working copy > > Hi > > I have a question about externals. I tried the following scenario in my > working copy: > > 1) Add an external definition to directory A, specifying subdirectory B > 2) Commit directory A > 3) Update directory A > > I then see A/B populated > > Then: > > 4) Edit external definition to directory A, specifying subdirectory C > 5) Commit directory A > 6) Update directory A > > I then see A/C populated, but directory A/B remains in the wc. > > If I checkout a new working copy, it shows A/C but not A/B, as expected. > > So, in short, changing an external definition on a directory seems not to > remove the previous external content from the committer's working copy. > > I hope this makes sense. Please will someone explain? > > Best regards > > David > > > > Click > https://www.mailcontrol.com/sr/nypLE7lZxS7TndxI!oX7UvIItv2OGGpTAw!IKZCqldsHAq!cPr+aidCSu5mXugUL!MaMXUtHUxa1yubdBaCdqw== > to report this email as spam. remove_externals Description: Binary data
Re: svn diff ignores externals
On 12 March 2010 15:03, Max wrote: > Hi, > > I have a repository with a structure which mixes some normal and external > repositories as follows > > - code_dir > | > `- src_dir > | > `- external_1 > | > `- dir_1 > | > `- external_2 > > where code_dir, src_dir and dir_1 are located on a repository under my > control, while external_1 and external_2 are defined by means svn:externals > keywords. > > I have noticed that old svn versions were able to track down modified files > both in dir_1 and external_* directories. The last version (I am running AFAIK subversion never stepped into externals folders, did it? If you want an svn command to run in the externals folder, you have to step into it (or supply it on the cmdline explicitly) ~Neels > 1.6.9) completely ignores external_1 and external_2 and give a list of > modified files located in dir_1 only. If I run "svn diff > code_dir/src_dir/external_1" I am able to see the list of modified files in > that directory too, of course. > > I know I am missing something trivial, but what? I have not found any hint in > the svn book... > > Thanks in advance for your help, > Max >
Re: 1.7.0 upgrade doesn't properly follow svn:externals
On 09/08/2011 06:21 PM, Scott Palmer wrote:
> Just tried 1.7.0RC2 and noticed that bugs with svn upgrade are still present.
>
> If you have svn:externals in the top level of your working copy they seem to
> be converted, but if those external references also use svn:externals then
> those nested working copies are not upgraded.
>
> Is anyone else seeing this?
Hi Scott,
thanks for the report! I can reproduce the problem with attached test
script. (The script uses my local bin/svn paths of built Subversion
versions, so I also attached a screenshot output.)
I am "moving" this discussion to the dev@ list, please reply there.
Note that the test upgrades the external dir XB, but fails to upgrade the
nested external dir XB/XC:
[[[
...
Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.
...
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
]]]
And note that a .svn dir remains in XB/XC (seen in the final 'ls')
I'll see if I can find a solution.
~Neels
#!/usr/bin/env 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
# current path points at Subversion 1.7.x. Change that to 1.6.x:
OLD_PATH="$PATH"
export PATH="$HOME/pat/1.6.17/prefix/bin:$OLD_PATH"
svn --version | grep version
BASE="$(mktemp -d "/tmp/$(basename "$0").XXX")"
echo "BASE = $BASE"
REPOS="$BASE/repos"
WC="$BASE/wc"
URL="file://$REPOS"
svnadmin create "$REPOS"
# enable all revprop changes
cat > "$REPOS/hooks/pre-revprop-change" < a
mkdir B
echo b > B/b
mkdir C
echo c > C/c
svn add a B C
svn ps svn:externals "^/C XC" B
svn ps svn:externals "^/B XB" .
svn ci -mm
svn up
# back to using Subversion 1.7.x
set +x
export PATH="$OLD_PATH"
set -x
svn --version | grep version
svn upgrade
ls -a XB/XC/
## END
set +x
echo "BASE = $BASE"
svn, version 1.7.0-dev (under development)
compiled Sep 7 2011, 21:15:48
Copyright (C) 2011 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
BASE = /tmp/palmer.AtX
+ svn --version
+ grep version
svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
+ svn co -q file:///tmp/palmer.AtX/repos /tmp/palmer.AtX/wc
+ cd /tmp/palmer.AtX/wc
+ echo a
+ mkdir B
+ echo b
+ mkdir C
+ echo c
+ svn add a B C
A a
A B
A B/b
A C
A C/c
+ svn ps svn:externals '^/C XC' B
property 'svn:externals' set on 'B'
+ svn ps svn:externals '^/B XB' .
property 'svn:externals' set on '.'
+ svn ci -mm
Sending.
Adding B
Adding B/b
Adding C
Adding C/c
Adding a
Transmitting file data ...
Committed revision 1.
+ svn up
Fetching external item into 'XB'
AXB/b
U XB
Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.
Updated to revision 1.
Fetching external item into 'B/XC'
AB/XC/c
Updated external to revision 1.
Updated to revision 1.
+ set +x
+ svn --version
+ grep version
svn, version 1.7.0-dev (under development)
Subversion is open source software, see http://subversion.apache.org/
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
+ ls -a XB/XC/
.
..
c
.svn
+ set +x
BASE = /tmp/palmer.AtX
signature.asc
Description: OpenPGP digital signature
Re: Apparent "svn rm" scaling problem in 1.7.x
On 11/01/2011 07:56 PM, Mark Phippard wrote: > On Tue, Nov 1, 2011 at 2:40 PM, Stefan Sperling <mailto:s...@elego.de>> wrote: > > On Tue, Nov 01, 2011 at 06:29:59PM +, Philip Martin wrote: > > I put in the ORDER BY to preserve the parents before children > > notification used by 1.6. I wonder if that notification order is > > important? > > See r1196191. > It should preserve the 1.6.x order (via svn_path_compare_paths()). > > > Just a side note. I have not been able to find a "final" version of the > svnbench tool with results for 1.7.0 compared with 1.6.17. The results I > can find are only comparing 1.7.x with trunk. Just wondering if those tests > show a problem with rm so that we can track progress via those tests. > > Adding Neels in case he archived any results. Have not, but I will gladly kick off a special run for you. (...some time passes...) See http://svn.haxx.se/dev/archive-2011-11/0029.shtml *Disclaimer:* this tests only file://-URL access on a GNU/Linux VM. This is intended to measure changes in performance of the local working copy layer, only. These results are *not* generally true for everyone. It seems to show an improvement on 'svn delete' for 1.7.0. ~Neels signature.asc Description: OpenPGP digital signature
Re: Apparent "svn rm" scaling problem in 1.7.x
On 11/02/2011 03:46 PM, Mark Phippard wrote: > On Wed, Nov 2, 2011 at 10:39 AM, Neels J Hofmeyr <mailto:ne...@elego.de>> wrote: > > > It seems to show an improvement on 'svn delete' for 1.7.0. > > > Yep, I noticed that. FWIW, the benchmarks that I wrote also show delete > being faster with 1.7.x: > > https://ctf.open.collab.net/sf/projects/csvn/ > > In my case, delete is deleting a folder that contains a lot of files. > Perhaps we need a test that is doing: > > $ svn rm folder/* > > That seems to be the main area where there is a problem. > > What does your delete test do? Hmm, not much. At one point it locally deletes a branch from a WC. I had more deletes in there originally, but that started to overcomplicate the test automation, so there isn't much deletion going on. I guess I should insert a few delete variants right at the end, now that I think of it from the distance. BTW, the commands are in tools/dev/benchmarks/suite1/benchmark.py starting at line 435. ~Neels signature.asc Description: OpenPGP digital signature
Re: Problems during merge
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
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
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 <http://www.projA.com> & > svn.projA.com <http://svn.projA.com>). > > I want that the svn.projA.com <http://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 <mailto: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@)
(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_absp
Re: Fwd: Serving internal SVN path via Apache
Itamar O wrote: > Thanks Neels, > Just tried that. > When accessing svn.proja.com <http://svn.proja.com> from a browser it > worked fine. > But checkout & list on svn.proja.com <http://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 <mailto:ne...@elego.de>> 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 <http://www.projA.com> > <http://www.projA.com> & > > svn.projA.com <http://svn.projA.com> <http://svn.projA.com>). > > > > I want that the svn.projA.com <http://svn.projA.com> > <http://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 <http://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> > <mailto:itamar...@gmail.com <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 <mailto:d...@subversion.apache.org> > <mailto:d...@subversion.apache.org <mailto: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: Problems during merge
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 &qu
Re: Serving internal SVN path via Apache
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
Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?
(This mail was posted to dev@ -- redirecting to users@) Johan Corveleyn wrote: > Hi devs, > > A small question in anticipation of 1.7: will an (FSFS) repo benifit > from a dump/reload when upgrading from 1.6 to 1.7? Or will a simple > "upgrade" (followed maybe by a "pack" to pack the revprops) provide > just the same? > > Reason for asking: We're currently still running on 1.5, and planning > to upgrade to 1.6 soon. Tests have shown us that doing a dump/reload > during this upgrade will give some benefit (due to rep-sharing > probably), but nothing huge. So I'm just wondering whether to do a > dump/reload now (to be in the best possible shape for the future), or > that I'll have to do another dump/reload when going to 1.7 in order to > get maximum benifits. In the latter case, I will probably not do a > dump/reload now (just upgrade to 1.6), and defer that until we upgrade > to 1.7... > > Kind regards, > Johan Just a side note, we are expecting most users to still be using 1.6 servers with their 1.7 clients for a while. But 1.7 will probably move to SHA1 checksums instead of MD5, and there will be some duplicate checksum calculation when pairing up a 1.7 client with older servers. ...but a) duplicate checksums might also be necessary even with 1.7 client <-> 1.7 server, and b) we don't expect *that* to impact performance, really. 1.7 servers may also allow you to obliterate revisions, but we don't know that yet. Anyone else know of a particular server side improvement planned for 1.7? (I'm rather ignorant, really) ~Neels signature.asc Description: OpenPGP digital signature
Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?
Sorry if I picked the wrong list there confusing Johan, but IMHO it *is* a users@ question. It is not about *writing* the API or code, it is about *using* the API/binaries, be it a future API or not. I agree that it's sort of in-between. What drove me to redirect to users@ is that others that read users@ might be asking themselves the same question. We posted both now anyways, probably for the best ;) About SHA1 on the 1.6 server: the point really is that we need to communicate those SHA1 checksums to the client and back. Those API mechanisms will be updated by 1.7 (or will they?). (I'm not 100% certain but that's how I understood the conversations so far. Please correct me if I'm wrong.) ~Neels Daniel Shahaf wrote: > Neels J Hofmeyr wrote on Mon, 22 Feb 2010 at 13:34 +0100: >> Johan, I think this mail should have been sent to users@ instead. I am >> replying there instead. > > It don't find it off-topic on dev@, though, given that it asks about > unreleased features. Not all devs read us...@. signature.asc Description: OpenPGP digital signature
Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?
Daniel Shahaf wrote: > Neels J Hofmeyr wrote on Mon, 22 Feb 2010 at 18:37 +0100: >> About SHA1 on the 1.6 server: the point really is that we need to >> communicate those SHA1 checksums to the client and back. Those API > > Communicate to the client? Eh? If those are the same checksums that go > into the rev file, I'd hope the server calculates them by itself and > doesn't rely on the client reporting them. (otherwise it would allow > malicious clients to corrupt the repository) You're right, wasn't thinking straight. Got mixed up with verifying the locally calculated checksum with the one from the server, which is of course entirely independent from what the client goes on to do with the data. ~Neels > >> mechanisms will be updated by 1.7 (or will they?). (I'm not 100% certain but >> that's how I understood the conversations so far. Please correct me if I'm >> wrong.) signature.asc Description: OpenPGP digital signature
