merge, --reintegrate, --record-only, near infinite regress in --use-merge-history
Bah!! (I'm a just a wee bit frustrated as I write this, please forgive
any roughness in tone.)
After waiting patiently for $JOB to finally move our server to
Subversion 1.6, I'm finding Subversion's merge tracking to be rather
less help than I'd hoped. (I guess git/hg/bzr have spoiled me during
my two year wait.)
What's really, really, really biting me at this point is a
modification of the --reintegrate workflow that I've seen described on
this list a few times:
usual way:
- create topic branch from trunk
- svn merge trunk topic
regularly during development to keep topic branch up-to-date with trunk
- svn merge --reintegrate topic trunk
merges the topic back to trunk
- svn rm topic
get rid of the topic branch. recreate if necessary.
as the next sync merge would cause it to try to pull
in its own reintegration leading to much gnashing
of teeth.
A few clever people suggested a way around the delete-and-recreate the
branch problem. Just use a record-only merge to make the topic branch
aware of the reintegration revision on trunk without actually enduring
the resulting conflicts.
It sounded like a great idea when I read it. Very clever.
Unfortunately, it's also *very* *broken*.
This technique interacts badly with "svn log -g". After a few repetitions of
merge, merge --record-only, merge --reintegrate, I'm finding the same
revisions showing up over and over again in my trunk when using svn log -g.
svn log -q | wc -l
2299
svn log -q -g | wc -l
14167
$ svn log -q -g | egrep -o -e "^r[0-9]+" | sort | uniq -c | sort -n | tail
131 r42278
135 r42171
135 r42251
135 r42252
136 r42196
136 r42205
136 r42219
136 r42223
191 r42282 <-- these two revisions appear 191 times in the log -g of trunk!
191 r42292 <--
When this has made svn log -g useless for me. ("Include merged
revisions" in TortoiseSVN is similarly useless). This is unfortunate,
because I had hoped that this feature would free me from having to
painstakingly protocol which revisions were merged in the log message
as I used to do in 1.4 days.
What's worse is that log -g uses historical information from the
repository (not just HEAD), so it's impossible to undo this error by
just deleting svn:merge-info properties and starting over. It appears
only dump, remove svn:merge-info properties, load of the whole
repository could fix things.
Is that my only way to correct this idiocy?
Does the Subversion Book include a big red warning label that I overlooked?
As a work-around, is there a way to limit the recursive depth of log -g?
// Ben
Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history
On Wed, Jun 02, 2010 at 11:33:21AM +0200, B Smith-Mannschott wrote:
> A few clever people suggested a way around the delete-and-recreate the
> branch problem. Just use a record-only merge to make the topic branch
> aware of the reintegration revision on trunk without actually enduring
> the resulting conflicts.
>
> It sounded like a great idea when I read it. Very clever.
>
> Unfortunately, it's also *very* *broken*.
>
> This technique interacts badly with "svn log -g". After a few repetitions of
> merge, merge --record-only, merge --reintegrate, I'm finding the same
> revisions showing up over and over again in my trunk when using svn log -g.
>
> svn log -q | wc -l
> 2299
>
> svn log -q -g | wc -l
> 14167
>
> $ svn log -q -g | egrep -o -e "^r[0-9]+" | sort | uniq -c | sort -n | tail
> 131 r42278
> 135 r42171
> 135 r42251
> 135 r42252
> 136 r42196
> 136 r42205
> 136 r42219
> 136 r42223
> 191 r42282 <-- these two revisions appear 191 times in the log -g of
> trunk!
> 191 r42292 <--
>
> When this has made svn log -g useless for me. ("Include merged
> revisions" in TortoiseSVN is similarly useless). This is unfortunate,
> because I had hoped that this feature would free me from having to
> painstakingly protocol which revisions were merged in the log message
> as I used to do in 1.4 days.
On the surface, this doesn't look like a merge-tracking problem.
It smells more like a presentation-layer bug (in log -g).
We should figure out how log -g should behave in this case (the behaviour
you're seeing clearly isn't desirable) and then fix it.
Please file an issue.
BTW, there's another known problem with the --reintegrate/--record-only trick,
with 2-URL merges: http://subversion.tigris.org/issues/show_bug.cgi?id=3648
Thanks,
Stefan
Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history
On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote: > We should figure out how log -g should behave in this case (the behaviour > you're seeing clearly isn't desirable) and then fix it. > Please file an issue. Oh, and if you can, please write a small script (attached to the issue) or test case (patch for our test suite) that shows the problem, by triggering a single revision to appear too many times in log -g output. That would help people who would like to investigate get started. Thanks, Stefan
[ANN] Artifacts for Web - free Subversion-style bug tracker
Dear Subversion users, We are pleased to announce the public availability of "Artifacts for Web" BETA - free web-based bug tracker. http://www.versioned.com/artifacts/web/ There is no need to install server software to use Artifacts. If you have a Subversion repository then you can start using a bug tracker in a matter of seconds. Artifacts for Web introduces a new approach to separation of logic and data. Data is stored and properly versioned in your Subversion repository. Logic to display and manage the data is loaded from our server and constantly updated with latest improvements and fixes. We would be happy to know your opinion about Artifacts. Thanks, Fyodor Sheremetyev Versioned Team
subversion-1.6.11 can not be compiled: dav_new_error incompatible
-- httpd-2.2.14/modules/dav/main/mod_dav.h : DAV_DECLARE(dav_error*) dav_new_error(apr_pool_t *p, int status, int error_id, const char *desc); -- httpd-2.3.5-alpha DAV_DECLARE(dav_error*) dav_new_error(apr_pool_t *p, int status, int error_id, apr_status_t aprerr, const char *desc); -- subversion-1.6.11: return dav_new_error(pool, HTTP_BAD_REQUEST, DAV_ERR_LOCK_SAVE_LOCK, "Only 'write' locks are supported."); return dav_new_error(repos->pool, HTTP_NOT_FOUND, 0, "could not find activity."); -- I use httpd-2.3.5-alpha :-( winfried Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events
RE: Merging branch back to trunk omits dirs and files that were added in the branch
The new directories did not exist in the trunk. I eventually "merged" my changes from the branch to the trunk by doing a diff between the working copies of the branch and trunk. The svn merge did get some of the changed files, but the tree conflicts seem random. I tried again this morning to reintegrate the branch to the trunk after mofifying four files. No additions or deletions, just 4 modified files. The svn merge created a few dozen tree conflicts. It marked as tree tree conflicts several of my top level build*.xml files that were not changed at all. It did pick up two of the changed files and merge them to the trunk. I used diff again and it showed the other two files unmerged - even though according to svn they had been merged. svn merging is completely broken. Tree conflicts are simply out of control. --- On Tue, 6/1/10, Jeremy Mordkoff wrote: From: Jeremy Mordkoff Subject: RE: Merging branch back to trunk omits dirs and files that were added in the branch To: "Dean Schulze" , users@subversion.apache.org Date: Tuesday, June 1, 2010, 1:35 PM Sounds like the target directories already existed in trunk. How did they get created? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com From: Dean Schulze [mailto:dean_w_schu...@yahoo.com] Sent: Tuesday, June 01, 2010 2:48 PM To: users@subversion.apache.org Subject: Merging branch back to trunk omits dirs and files that were added in the branch I've tried this with both TortoiseSVN and the merge tool that comes with Subclipse. I've added subdirectories with files under several directories on the branch (along with many other changes). When I merge back to the trunk the top level directories under which I added the subdirectories and files show up as tree conflicts. None of the sub-directories or files show up. I mark the tree conflicts as resolved (I mark all tree conflicts as resolved choosing the repository / branch file whenever asked to resolve manually). In the merged trunk the new subdirectories and files are missing all together. The trunk svn:mergeinfo shows the correct range of revisions. What do I have to do to simply merge the branch back to the trunk? Firstly, this is not a conflict of any kind. I added those directories and files intentionally. Secondly, ever since tree conflicts were added to svn I've found svn to be completely unreliable when it comes to merging. How do I turn off tree conflicts (eliminate them all together)? What do I have to do to get back to reliable merging, switch to git?
Re: How to build with http/https: access via serf, and not neon?
On Tuesday 01 Jun 2010, yary wrote: > Neon is required? The INSTALL that comes with 1.6.11 says that either > neon or serf will give http access: > > * libneon or libserf (OPTIONAL for client) > > The Neon and Serf libraries both allow the Subversion client > to send HTTP requests. ... Your client can be compiled against > either libneon or libserf (or both), as they offer competing > implementations. > > -y It's possible the configure script isn't detecting either library on your system and so isn't including the necessary commands in the makefiles. I have two examples of configure lines, one with neon specified and one without and both create working binaries. I think I needed to specify it because I was building a static binary or needed a specific version. At the very simplest though the following commands work on my machine: tar xfvj subversion-1.6.11.tar.bz2 tar xfvj subversion-deps-1.6.11.tar.bz2 cd subversion-1.6.11/ ./configure --with-ssl make however your mileage may vary depending on the libraries installed. I can confirm I have packages for libneon and neon installed on my opensuse desktop. Neon and serf are provided in the dependencies because they must be needed at some point and I had the impression at least some of the dependencies were picked up automatically if necessary but I guess this isn't always the case. Campbell __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Re: How to build with http/https: access via serf, and not neon?
Hi Campbell, I can build a working binary as well, it's just that the client doesn't have the http: method when built with only serf and "--without-neon". It sounds like you're building it with neon in each cases, just not using the "--with-neon" flag; omitting the flag makes configure look for it in the default places. Have you tried building using "without-neon", if so can you verify that yours shows http when you run "svn --version"? I'm wondering if this is simply a documentation bug, that neon is always required in some respect. -y
Unexpected tree conflict when deleting directory
Hi, I'm experiencing a tree conflict in a situation where there should be no conflict. Basically, after removing the contents of a directory I'm unable to commit deleting the directory even though no one has modified it. The client is 1.6.6. I've tried with server versions 1.4.3 and 1.6.9. Below is a simple demonstration $ mkdir foo $ svn add foo/ A foo $ svn commit -m "Add dir foo" Adding foo Committed revision 1738. $ echo 'Hello World' > foo/bar $ svn add foo/bar A foo/bar $ svn commit -m "Add file bar in dir foo" Adding foo/bar Transmitting file data . Committed revision 1739. $ svn rm foo/bar D foo/bar $ svn commit -m "Remove file bar from dir foo" Deleting foo/bar Committed revision 1740. $ svn rm foo/ D foo $ svn commit -m "Remove directory foo" Deleting foo svn: Commit failed (details follow): svn: Item '/puppet/foo' is out of date $ svn update C foo At revision 1740. Summary of conflicts: Tree conflicts: 1 At this point, I have to use 'svn resolve --accept working foo/' to accept the deletion. Afterwards, I can successfully commit it. Can anyone explain this behavior? -- Brian Pitts Systems Administrator | EuPathDB Bioinformatics Resource Center 706-542-1447 | b...@uga.edu | http://eupathdb.org
Re: How to build with http/https: access via serf, and not neon?
On Wednesday 02 Jun 2010, yary wrote: > Hi Campbell, > > I can build a working binary as well, it's just that the client > doesn't have the http: method when built with only serf and > "--without-neon". It sounds like you're building it with neon in each > cases, just not using the "--with-neon" flag; omitting the flag makes > configure look for it in the default places. Have you tried building > using "without-neon", if so can you verify that yours shows http when > you run "svn --version"? > > I'm wondering if this is simply a documentation bug, that neon is > always required in some respect. > > -y I feel there's been a bit of confusion, by working I was meaning with http support. I understand now. Same instructions but with a --without-neon still works with http: svn, version 1.6.11 (r934486) compiled Jun 2 2010, 17:44:52 ... * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme In the configure output I also get the bit about not having neon. Just below it is the section configuring serf. This sounds like it is different because you have it already. In that case I'm wondering if you need to add explicit references to the directories to include the library. I had to do this on my server build script to pick up openssl. Something like? LDFLAGS=-L/usr/local/serf/lib CPPFLAGS=-I/usr/local/serv/include export LDFLAGS CPPFLAGS Here's the output from my configure in case it sheds some light on the differences. apr-util configured properly checking APR-UTIL version... 1.3.9 checking for pkg-config... /usr/bin/pkg-config configure: checking neon library An appropriate version of neon could not be found, so libsvn_ra_neon will not be built. If you want to build libsvn_ra_neon, please either install neon 0.29.0 on this system or get neon 0.29.0 from: http://www.webdav.org/neon/neon-0.29.0.tar.gz unpack the archive using tar/gunzip and rename the resulting directory from ./neon-0.29.0/ to ./neon/ no suitable neon found checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes configure: configuring package in serf now checking for chosen layout... Serf checking for working mkdir -p... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Configuring Apache Portable Runtime library... checking for APR... yes setting CC to "gcc" setting CPP to "gcc -E" setting APR_LIBTOOL to "/export/home/campa/Download/new/subversion-1.6.11/apr/libtool" setting CFLAGS to " -g -O2 -pthread" setting CPPFLAGS to " -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE" setting LDFLAGS to " " setting LTFLAGS to "--silent" Configuring Apache Portable Runtime Utility library... checking for APR-util... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for a BSD-compatible install... /usr/bin/install -c Configuring Serf... checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking for library containing fabs... -lm setting SERF_LIBS to " /export/home/campa/Download/new/subversion-1.6.11/apr-util/libaprutil-1.la /export/home/campa/Download/new/subversion-1.6.11/apr-util/xml/expat/lib/libexpat.la /export/home/campa/Download/new/subversion-1.6.11/apr/libapr-1.la -lrt -lcrypt -lpthread -ldl -lm " configure: creating ./config.status config.status: creating Makefile config.status: executing mkdir-vpath commands serf configured properly -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. T
Vague error with subversion + apache22 + freebsd
Hi, I'm getting a vague error. I have subversion set up through apache on freebsd(all installed through ports). I'm working with a large repository containing lots of large files which I've migrated over from an older similar install on another machine using svnadmin dump/ restore. I can navigate to the repository in firefox, see, and download files (including large binary files) without any problem. I can check out portions of the repository from the command line using http on the machine running the server (svn checkout http://my.host.name/vault) without a problem. However, when doing a checkout onto any other remote system (windows or unix, using command line, or tortoisesvn), it grabs the first few folders but on hitting the first file(happens to be about 14mb) it gives this error: svn: REPORT of '/vault/!svn/vcc/default': 200 OK (http://my.host.name) On the server side I get the following errors from apache: [Wed Jun 02 13:43:10 2010] [info] [client X.X.X.X] (32)Broken pipe: core_output_filter: writing data to the network [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Provider encountered an error while streaming a REPORT response. [500, #0] [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] A failure occurred while driving the update report editor [500, #53] [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Error writing base64 data: Software caused connection abort [500, #53] I'm running: svn, version 1.6.11 (r934486) Server version: Apache/2.2.15 (FreeBSD) FreeBSD 8.0-RELEASE I've dug around and seen people with similar messages, either related to problems not applicable to my setup or bugs fixed in earlier versions of subversion. Any ideas for things to try would be greatly appreciated. Thanks, Michael
Re: proposed export option
Hello, I previously inquired about adding a –skipfilesmatchingsize option to the export subcommand. I have implemented that feature, and I was wondering if it has any chance of making it into the trunk directory for svn. It currently has performance issues, and I don't want to spend a lot of time optimizing the code if it's never going to be incorporated into the main development line. If the feature is not acceptable as described in my previous message, could it be made acceptable if it were expanded somehow to make it of more general use? Maybe by using checksums instead of file size or, more ambitiously, I was thinking something like a rsync subcommand that allows a person to synchronize an unversioned folder with an svn repository. Any comments or suggestions would be greatly appreciated. --Paul Breen --- On Mon, 4/26/10, Paul Breen wrote: > From: Paul Breen > Subject: proposed export option > To: users@subversion.apache.org > Date: Monday, April 26, 2010, 11:07 PM > Hello, > > I'd like to add a new option to the export command that > allows the user > to export files only if the file size has > changed--something like > > svn export --skipfilesmatchingsize > > The idea is to do a quick-and-easy, traffic-minimizing > deployment of > files that are unlikely to remain the same size when > modified. I'm > doing this as a project for a client who would like the > change to be > incorporated into a release version on Collabnet's > website. I'm new > to subversion development, and I'm looking for any advice > or > suggestions the developers here may have regarding the > proposition. > > Thanks, > > Paul Breen >
Re: Unexpected tree conflict when deleting directory
On Wed, Jun 02, 2010 at 01:04:38PM -0400, Brian Pitts wrote: > Hi, > > I'm experiencing a tree conflict in a situation where there should be no > conflict. Basically, after removing the contents of a directory I'm > unable to commit deleting the directory even though no one has modified > it. The client is 1.6.6. I've tried with server versions 1.4.3 and > 1.6.9. Below is a simple demonstration > > $ mkdir foo > $ svn add foo/ > A foo > $ svn commit -m "Add dir foo" > Adding foo > > Committed revision 1738. > $ echo 'Hello World' > foo/bar > $ svn add foo/bar > A foo/bar > $ svn commit -m "Add file bar in dir foo" > Adding foo/bar > Transmitting file data . > Committed revision 1739. > $ svn rm foo/bar > D foo/bar > $ svn commit -m "Remove file bar from dir foo" > Deleting foo/bar > > Committed revision 1740. Look at the output of svn info foo at this point. You'll see that foo is not at the HEAD revision, i.e. something older than 1740. foo/bar was bumped to the HEAD revision because it was a commit target. But foo was not a commit target so it is left at whichever revision it was before you started the commit. This is called a "mixed-revision" working copy. See http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs So foo is now out of date. You need to update now, *before* removing the directory. But you didn't do so. > $ svn rm foo/ > D foo Because you did not update, you have just deleted a directory which is based on an outdated revision (i.e. not HEAD). In general, deleting or moving or copying things in a mixed-revision working copy is a bad idea. Try to avoid doing so. Copy, move, and delete can operate on URLs directly, without needing a working copy. Using URLs avoids problems arising from mixed-revision working copies. > $ svn commit -m "Remove directory foo" > Deleting foo > svn: Commit failed (details follow): > svn: Item '/puppet/foo' is out of date > $ svn update >C foo > At revision 1740. > Summary of conflicts: > Tree conflicts: 1 svn status now says the tree conflict is "local delete, incoming edit upon update" The incoming edit in this case is the delete of the child foo/bar. Subversion cannot tell whether the incoming change was committed from your own working copy or not. Nor should it care. It simply wants to update the directory foo from an older revision to HEAD. To do this it needs to change something inside of foo (delete foo/bar). But you have locally deleted foo, so Subversion cannot apply the incoming change! So there's a conflict. > At this point, I have to use 'svn resolve --accept working foo/' to > accept the deletion. Afterwards, I can successfully commit it. Can > anyone explain this behavior? This is called a "self-inflicted" tree conflict. This has been discussed a few times, for example here: http://old.nabble.com/Cannot-commit-moved-directory-after-adding-%28and-committing%29-a-child-td25191764.html http://svn.haxx.se/dev/archive-2010-03/0496.shtml Hope this helped, Stefan
Re: merge, --reintegrate, --record-only, near infinite regress in --use-merge-history
On Wed, Jun 2, 2010 at 12:46, Stefan Sperling wrote: > On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote: >> We should figure out how log -g should behave in this case (the behaviour >> you're seeing clearly isn't desirable) and then fix it. >> Please file an issue. > > Oh, and if you can, please write a small script (attached to the issue) > or test case (patch for our test suite) that shows the problem, > by triggering a single revision to appear too many times in log -g output. > That would help people who would like to investigate get started. > > Thanks, > Stefan > http://subversion.tigris.org/issues/show_bug.cgi?id=3650
Re: Unexpected tree conflict when deleting directory
On 06/02/2010 04:04 PM, Stefan Sperling wrote: Look at the output of svn info foo at this point. You'll see that foo is not at the HEAD revision, i.e. something older than 1740. foo/bar was bumped to the HEAD revision because it was a commit target. But foo was not a commit target so it is left at whichever revision it was before you started the commit. This is called a "mixed-revision" working copy. See http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs So foo is now out of date. You need to update now, *before* removing the directory. But you didn't do so. Because you did not update, you have just deleted a directory which is based on an outdated revision (i.e. not HEAD). In general, deleting or moving or copying things in a mixed-revision working copy is a bad idea. Try to avoid doing so. Copy, move, and delete can operate on URLs directly, without needing a working copy. Using URLs avoids problems arising from mixed-revision working copies. svn status now says the tree conflict is "local delete, incoming edit upon update" The incoming edit in this case is the delete of the child foo/bar. Subversion cannot tell whether the incoming change was committed from your own working copy or not. Nor should it care. It simply wants to update the directory foo from an older revision to HEAD. To do this it needs to change something inside of foo (delete foo/bar). But you have locally deleted foo, so Subversion cannot apply the incoming change! So there's a conflict. Thanks you for the detailed explanation. It is a little hard to wrap my head around the idea that although I committed the change deleting foo/bar, I now have to update foo/ for my working copy to truly reflect that foo/bar is deleted. To paraphrase Johan from #3256, 'what "incoming edit"? Bumping the revision number? The deleted file is already gone'. I understand if this counter intuitive behavior is the natural consequence of the way subversion is designed and is difficult to change. However, perhaps there is a way to make this situation easier fo users to understand or avoid? My first thought is that performing deletes/moves/copies on an item that is not at HEAD could display a warning message. -- Brian Pitts Systems Administrator | EuPathDB Bioinformatics Resource Center 706-542-1447 | b...@uga.edu | http://eupathdb.org
Re: Unexpected tree conflict when deleting directory
On Wed, Jun 02, 2010 at 05:45:53PM -0400, Brian Pitts wrote: > It is a little hard to wrap my head around the idea that although I > committed the change deleting foo/bar, I now have to update foo/ for > my working copy to truly reflect that foo/bar is deleted. To > paraphrase Johan from #3256, 'what "incoming edit"? Bumping the > revision number? The deleted file is already gone'. Well... it's gone in *HEAD* :) The item is still present in past revisions. If you checked out the parent as of before you deleted the file, you'd rightly expect the file to show up in your working copy. A parent dir that is out-of-date has no way of knowing what happened to its children in the future. At the time the tree conflict check is made, we don't even know what changes the server wants to send for the directory. All we know is that it wants to change something inside the directory. And it does not matter what changes will be sent, because if the directory isn't there (locally deleted), we cannot apply any changes anyway. You happen to know that the incoming change is no-op, that it comes from the very same working copy, and that no other commit happened in-between. So the present state happens to semantically not conflict with the incoming change. But Subversion doesn't know that. Any kinds of changes could have happened between the directory's current revision and HEAD. For all we know the child you deleted could have been re-added already, in which case deleting the parent directory conflicts with the re-addition of the child. Maybe svn could be a bit smarter about this, that would be nice. But trying to be smarter can get really complicated very quickly. > I understand if this counter intuitive behavior is the natural > consequence of the way subversion is designed and is difficult to > change. Absolutely. But I'd argue that it's only counter-intuitive if you haven't understood how Subversion works. At least the parts where you have one new revision of the entire repository tree for every commit, and where your working copy is usually a hodgepodge of many of those revisions. The rest follows from there. > However, perhaps there is a way to make this situation > easier fo users to understand or avoid? My first thought is that > performing deletes/moves/copies on an item that is not at HEAD could > display a warning message. I don't think such a warning would help much. The moved item could be outdated a split-second after the move completes, because a commit can happen any time. A warning that triggers if an item is moved within a mixed-revision working copy might help. Then again, people would probably see this warning a lot, so it would be an annoyance (e.g. one extra click for every delete/move/copy operation in TortoiseSVN). And it would make the situation seem a lot more dramatic than it really is. After all, you already knew how to resolve the conflict before you understood why it even happened. Stefan
Re: proposed export option
On Jun 2, 2010, at 13:48, Paul Breen wrote: > I previously inquired about adding a –skipfilesmatchingsize option to the > export subcommand. I have implemented that feature, and I was wondering if > it has any chance of making it into the trunk directory for svn. It > currently has performance issues, and I don't want to spend a lot of time > optimizing the code if it's never going to be incorporated into the main > development line. > > If the feature is not acceptable as described in my previous message, could > it be made acceptable if it were expanded somehow to make it of more general > use? Maybe by using checksums instead of file size or, more ambitiously, I > was thinking something like a rsync subcommand that allows a person to > synchronize an unversioned folder with an svn repository. > > Any comments or suggestions would be greatly appreciated. You recall that there was already a discussion in April when you initially suggested this feature? http://svn.haxx.se/users/archive-2010-04/index.shtml#405 There were objections by myself and others that what you proposed was already fairly easily accomplished using Subversion's existing commands, and you were going to inquire with your client as to why those existing methods weren't suitable.
Re: Vague error with subversion + apache22 + freebsd
On Wed, Jun 2, 2010 at 8:46 PM, Michael Zatopek wrote: > Hi, > > I'm getting a vague error. I have subversion set up through apache on > freebsd(all installed through ports). I'm working with a large repository > containing lots of large files which I've migrated over from an older > similar install on another machine using svnadmin dump/restore. > > I can navigate to the repository in firefox, see, and download files > (including large binary files) without any problem. I can check out portions > of the repository from the command line using http on the machine running > the server (svn checkout http://my.host.name/vault) without a problem. > > However, when doing a checkout onto any other remote system (windows or > unix, using command line, or tortoisesvn), it grabs the first few folders > but on hitting the first file(happens to be about 14mb) it gives this error: > > svn: REPORT of '/vault/!svn/vcc/default': 200 OK (http://my.host.name) > > On the server side I get the following errors from apache: > > [Wed Jun 02 13:43:10 2010] [info] [client X.X.X.X] (32)Broken pipe: > core_output_filter: writing data to the network > [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Provider encountered an > error while streaming a REPORT response. [500, #0] > [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] A failure occurred while > driving the update report editor [500, #53] > [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Error writing base64 > data: Software caused connection abort [500, #53] > > I'm running: > svn, version 1.6.11 (r934486) > Server version: Apache/2.2.15 (FreeBSD) > FreeBSD 8.0-RELEASE > > I've dug around and seen people with similar messages, either related to > problems not applicable to my setup or bugs fixed in earlier versions of > subversion. > > Any ideas for things to try would be greatly appreciated. Just a quick drive-by shot: take a look at networking components between client and server (firewalls, proxies, ...). My prime suspect would be a proxy (or proxy settings). Some proxies don't interoperate well with svn (more particularly, some proxies have trouble with some of the WebDAV methods that svn uses). If there's no proxy and no firewall involved, I have no idea ... Cheers, -- Johan
Re: post-commit script sends a void message
Ryan Schmidt wrote on Tue, 1 Jun 2010 at 16:23 -0500: > On Jun 1, 2010, at 06:52, Mauro Gatti wrote: > > [ ... about post-commit hooks ... ] > > Hmm. I wasn't aware it was possible for $1 to not contain the full > absolute path to the repository. I wonder why in your case it isn't. The code doesn't make svn_repos_t.path absolute anywhere. I guess it'll be relative path if the user gives the repository path as a relative path (possibly in svnserve/httpd's configuration).
Re: proposed export option
Ryan Schmidt wrote on Wed, 2 Jun 2010 at 17:35 -0500: > On Jun 2, 2010, at 13:48, Paul Breen wrote: > > > I previously inquired about adding a –skipfilesmatchingsize option > > to the export subcommand. I have implemented that feature, and > > I was wondering if it has any chance of making it into the trunk > > directory for svn. It currently has performance issues, and I don't > > want to spend a lot of time optimizing the code if it's never going > > to be incorporated into the main development line. > > > > If the feature is not acceptable as described in my previous > > message, could it be made acceptable if it were expanded somehow to > > make it of more general use? Maybe by using checksums instead of > > file size or, more ambitiously, I was thinking something like > > a rsync subcommand that allows a person to synchronize an > > unversioned folder with an svn repository. > > svn checkout --force (will convert a .svn-less tree into a working copy) > > Any comments or suggestions would be greatly appreciated. > > You recall that there was already a discussion in April when you > initially suggested this feature? > > http://svn.haxx.se/users/archive-2010-04/index.shtml#405 > > There were objections by myself and others that what you proposed was > already fairly easily accomplished using Subversion's existing > commands, and you were going to inquire with your client as to why > those existing methods weren't suitable. > > >
Re: [ANN] Artifacts for Web - free Subversion-style bug tracker
This is very interesting. But it looks to me like it links to javascript on your server in order to function? In other words, if I need access to my bug tracker and your server is - for some reason - offline, I'm SOL? Thanks Rob Fyodor Sheremetyev wrote: Dear Subversion users, We are pleased to announce the public availability of "Artifacts for Web" BETA - free web-based bug tracker. http://www.versioned.com/artifacts/web/ There is no need to install server software to use Artifacts. If you have a Subversion repository then you can start using a bug tracker in a matter of seconds. Artifacts for Web introduces a new approach to separation of logic and data. Data is stored and properly versioned in your Subversion repository. Logic to display and manage the data is loaded from our server and constantly updated with latest improvements and fixes. We would be happy to know your opinion about Artifacts. Thanks, Fyodor Sheremetyev Versioned Team
make error
I use all the subversion version, all the error, how are make not the past, please help us to see what it is. [r...@localhost subversion-1.6.11]# make /bin/sh /opt/src/subversion-1.6.11/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -g -O2 -pthread -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/local/apache2/include -I./subversion/include -I./subversion -I/usr/local/subversion/apr/include/apr-1 -I/usr/local/subversion/apr-util/include/apr-1 -I/usr/local/subversion/neon/include/neon -I/usr/local/subversion/serf/include/serf-0 -I/usr/local/subversion/sqlite/include -I/usr/local/subversion/zlib/include -o subversion/mod_dav_svn/activity.lo -c subversion/mod_dav_svn/activity.c subversion/mod_dav_svn/activity.c: In function `dav_svn__delete_activity': subversion/mod_dav_svn/activity.c:163: warning: passing arg 4 of `dav_new_error' makes integer from pointer without a cast subversion/mod_dav_svn/activity.c:163: error: too few arguments to function `dav_new_error' make: *** [subversion/mod_dav_svn/activity.lo] Error 1 [r...@localhost subversion-1.6.11]# ls aclocal.m4 BUGS CHANGES config.status COPYING HACKING Makefile notes sqlite-amalgamation TRANSLATING apr build COMMITTERS configure doc INSTALL Makefile.in packages subversion win-tests.py apr-utilbuild.confconfig.log configure.ac gen-make.opts libtool mkmf.log READMEtemp www autogen.sh build-outputs.mk config.nice contribgen-make.py libtool.old neon serf toolszlib $ ./configure --prefix=/usr/local/subversion --with-apr=/usr/local/subversion/apr --with-apr-util=/usr/local/subversion/apr-util --with-neon=/usr/local/subversion/ne on --with-serf=/usr/local/subversion/serf --with-sqlite=/usr/local/subversion/sqlite --with-zlib=/usr/local/subversion/zlib 2010-06-03 北京华拓信通科技有限公司 ―― 北京.海淀.紫竹院路116号嘉豪国际中心C座1115室 邮编：100097 电话：010-51709655-813 传真：010-51709657 手机：13581952339 E-mail:gq...@hwatop.com Web：www.hwatop.com ――
Re: make error
On Jun 2, 2010, at 21:56, 刘国庆 wrote: > I use all the subversion version, all the error, how are make not the past, > please help us to see what it is. > > > [r...@localhost subversion-1.6.11]# make > /bin/sh /opt/src/subversion-1.6.11/libtool --tag=CC --silent --mode=compile > gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -g > -O2 -pthread -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/local/apache2/include > -I./subversion/include -I./subversion > -I/usr/local/subversion/apr/include/apr-1 > -I/usr/local/subversion/apr-util/include/apr-1 > -I/usr/local/subversion/neon/include/neon > -I/usr/local/subversion/serf/include/serf-0 > -I/usr/local/subversion/sqlite/include -I/usr/local/subversion/zlib/include > -o subversion/mod_dav_svn/activity.lo -c subversion/mod_dav_svn/activity.c > subversion/mod_dav_svn/activity.c: In function `dav_svn__delete_activity': > subversion/mod_dav_svn/activity.c:163: warning: passing arg 4 of > `dav_new_error' makes integer from pointer without a cast > subversion/mod_dav_svn/activity.c:163: error: too few arguments to function > `dav_new_error' > make: *** [subversion/mod_dav_svn/activity.lo] Error 1 > > > [r...@localhost subversion-1.6.11]# ls > aclocal.m4 BUGS CHANGES config.status COPYING > HACKING Makefile notes sqlite-amalgamation TRANSLATING > apr build COMMITTERS configure doc > INSTALL Makefile.in packages subversion win-tests.py > apr-utilbuild.confconfig.log configure.ac gen-make.opts > libtool mkmf.log READMEtemp www > autogen.sh build-outputs.mk config.nice contribgen-make.py > libtool.old neon serf toolszlib > > > $ ./configure --prefix=/usr/local/subversion > --with-apr=/usr/local/subversion/apr > --with-apr-util=/usr/local/subversion/apr-util > --with-neon=/usr/local/subversion/ne > on --with-serf=/usr/local/subversion/serf > --with-sqlite=/usr/local/subversion/sqlite > --with-zlib=/usr/local/subversion/zlib You seem to be describing the same problem Winfried did earlier today: that mod_dav_svn appears to be incompatible with Apache 2.3.x at this time: http://svn.haxx.se/users/archive-2010-06/0025.shtml I assume you are using Apache 2.3.x?
