Disable diff-cmd
Hello, Is there any way to disable diff-cmd setting for just one run of svn diff? I need it for code review upload script, which fails when users have configured graphical diff. Is there any way to force svn use internal diff implemantation? I've tried: svn diff --config-option config:helpers:diff-cmd= svn diff --diff-cmd svn diff --diff-cmd NUL with no effect. Please, CC. -- anatoly t.
Re: merging into locally added files
On Tue, 2010-08-24, Stefan Sperling wrote: On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote: You seem to be talking only about the case where the (locally added) target is the root of the whole merge, and saying that lack of ancestral relationship between the source node and this target node doesn't matter. Maybe the user performing the merge is fully aware of what he/she is doing, which is fine in this simple case. But what about the general case, where the modification to a locally added node may be somewhere deep down in a merge that's supposed to be a simple automatic merge? I don't think locally added nodes somewhere deep within the merge target are affected by this change. Those should be handled by the regular tree conflict logic. The change only affects the merge target root, which can now be a locally added file or directory. Previously, Subversion just errored out on locally added merge target roots and didn't merge anything at all. Oh, OK! That makes sense then. - Julian
Re: svn diff optimization to make blame faster?
On Sun, Aug 22, 2010 at 4:02 PM, Branko Čibej br...@xbc.nu wrote: On 18.08.2010 00:59, Johan Corveleyn wrote: Hi devs, While Looking to improve performance of svn annotate [1], I found that the current blame algorithm is mainly client-side bound, and that most of its time is spent on svn diff (calls to svn_diff_file_diff_2 from add_file_blame in blame.c). Apart from avoiding to build full-texts and diffing them altogether (which is subject of further discussion in [1]), I'm wondering if optimization of svn diff wouldn't also be an interesting way to improve the speed of blame. So the main question is: is it worth it to spend time to analyze this further and try to improve performance? Or has this already been optimized in the past, or is it simply already as optimal as it can get? I have no idea really, so if anyone can shed some light ... Gut feeling tells me that there must be room for optimization, since GNU diff seems a lot faster than svn diff for the same large file (with one line changed) on my machine [1]. But maybe svn's diff algorithm is purposefully different (better? more accurate? ...) than GNU's, or there are specific things in the svn context so svn diff has to do more work. Any thoughts? svn_diff uses basically the same algorithm as GNU diff but implemented slightly differently and IIRC it doesn't have some of GNU diff's optimizations. I'm sure it can be speeded up, but haven't a clue about how much. Ok, thanks. In the meantime I saw that there is not that much difference anymore between GNU diff and svn_diff, after running the latter from a release build, and disabling my anti-virus (which makes me wonder why my anti-virus slows down svn_diff (impact when opening the modified datasource), but not on GNU diff). There may still be some slight speed difference (enough to be significant for a blame operation doing 100's or 1000's of diffs), but not that much as I thought at first. So I don't think I'm going to spend more time on trying to speed up svn_diff (also, I'm not really an expert at optimizing C code, so ... I'll leave that to others :-)). Cheers, -- Johan
Re: Looking to improve performance of svn annotate
On Fri, Aug 20, 2010 at 9:11 PM, Johan Corveleyn jcor...@gmail.com wrote: On Fri, Aug 20, 2010 at 1:40 PM, Johan Corveleyn jcor...@gmail.com wrote: After eliminating antivirus, and running with a release build instead of a debug build, svn diff is just about on par with GNU diff. So this eliminates the option of optimizing diff ... Unless ... For every diff during blame calculation, tokens (lines) are extracted and processed each time for the original and the modified. This takes up most of the time of svn diff. However, the file that is playing the modified role in one step, will be the original in the next step of blame processing. So in theory we already have those tokens from the previous step, and don't have to extract/compare/... them again. If one could find a way to recycle the tokens from the modified of the previous diff into the tokens of the original of the next diff, that would probably make the diff part of the blame operation almost twice as fast. And since diffing still accounts for ~90% of blame time on the client, that should speed it up considerably. Sounds like a plan? I'll try to write some sort of POC for this idea soon, unless someone tells me it's a stupid idea :-). Hm, after several attempts to get this working, it seems to be a dead end. Whatever I do, I can't seem to avoid lifetime issues, dangling pointers, tokens referring to files which are no longer there, ... I first tried just to pass through the position_list[1] (position_list from the modified file) to the next diff run as the new position_list[0]. I did this by returning the position_list[1] in an output parameter, up to the call in blame.c!add_file_blame, and then reusing that as input parameter for the next diff call (by stashing it away in the file_rev_baton, until the next run). That works, but it doesn't help, because the real power of the algorithm is in the tree, in which all the tokens from both original and modified are sorted and made unique (i.e. each unique token is represented only once in the tree). After the tree is correctly set up, the rest of the algo is very fast, because it only needs to compare token references to find the longest common subsequence. At the end of each run the tree is filled with a combination of the tokens of original and modified, so I can't just reuse/recycle that, because that would lead to a major memory leak (building up the tree with all the tokens from all revisions of the entire blame operation). And refilling a clean tree with the tokens already present in the passed-on-position_list also doesn't work, because the token content really needs to still be accessible (either in memory, or readable from the original file), so that token_compare can work when adding the new tokens from the new modified file ... Anyway, I don't know if this still makes sense. I'm just noting it down to order my thoughts, and maybe help someone else thinking about this. I'm gonna let it rest now, because I seem to have hit a brick wall with this. Will focus my efforts on other approaches to speed up blame, such as the fundamental changes of binary blaming, avoiding diffs, ... but I'm not sure if I'll be able to (have the time to) climb the learning curve for that. Cheers, -- Johan
Re: Disable diff-cmd
On Tue, 24 Aug 2010, anatoly techtonik wrote: Hello, Is there any way to disable diff-cmd setting for just one run of svn diff? I need it for code review upload script, which fails when users have configured graphical diff. Is there any way to force svn use internal diff implemantation? I've tried: svn diff --config-option config:helpers:diff-cmd= svn diff --diff-cmd svn diff --diff-cmd NUL with no effect. --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. HTH Martin
Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
Bert Huijben b...@vmoo.com writes: * subversion/tests/cmdline/upgrade_tests.py (text_base_path): Restore MD5 support removed in r960036. I think the real fix would be to upgrade to SHA1 (and add the mapping in the pristines table) in the upgrade step. I expected that this was already handled? Yes, that needs to happen, and no, it doesn't happen yet. The new code stores SHA1 on checkout/update but the upgrade code simply copies the MD5 and doesn't do MD5 to SHA1 conversion. I discussed this with Julian on IRC yesterday, the plan is to remove the MD5 support eventually. There are two cases to consider, upgrade from 1.6 to latest and upgrade from older 1.7 to latest. For the older 1.7 upgrade we can simply use the PRISTINE table to replace the MD5 with the corresponding SHA1 in the bump_to_19 code. The 1.6 upgrade is a bit harder. We can do the text-base to pristine before doing the entries file, so that the PRISTINE table is available, but the table is not currently indexed on MD5. As there is now only one table per wc it might be too slow if there are lots of files. We may need an MD5 index, as part of PRISTINE or separate, just for the duration of the upgrade. The bump_to_19 code can do the MD5 to SHA1 conversion before switching to single-db, the table is smaller and may not need an MD5 index (and the bump_to_19 code simply isn't as important as the 1.6 upgrade code). -- Philip
Re: svn diff optimization to make blame faster?
Johan Corveleyn jcor...@gmail.com writes: Ok, thanks. In the meantime I saw that there is not that much difference anymore between GNU diff and svn_diff, after running the latter from a release build, and disabling my anti-virus (which makes me wonder why my anti-virus slows down svn_diff (impact when opening the modified datasource), but not on GNU diff). The big difference between Subversion's diff and GNU diff is that GNU uses heuristics to cut short the diff algorithm whereas Subversion grinds on to the end. Certain files trigger the heuristics and then GNU diff is much faster than Subversion. Typically the file has a large number of matches and non-matches repeated through the file, machine generated files sometimes fit this pattern. GNU diff's heuristics work well so when they trigger the resulting diff is usually good enough. They can be disabled using the --minimal option and using that makes GNU diff performance much more like Subversion. -- Philip
RE: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: dinsdag 24 augustus 2010 10:40 To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py Bert Huijben b...@vmoo.com writes: * subversion/tests/cmdline/upgrade_tests.py (text_base_path): Restore MD5 support removed in r960036. I think the real fix would be to upgrade to SHA1 (and add the mapping in the pristines table) in the upgrade step. I expected that this was already handled? Yes, that needs to happen, and no, it doesn't happen yet. The new code stores SHA1 on checkout/update but the upgrade code simply copies the MD5 and doesn't do MD5 to SHA1 conversion. I discussed this with Julian on IRC yesterday, the plan is to remove the MD5 support eventually. There are two cases to consider, upgrade from 1.6 to latest and upgrade from older 1.7 to latest. For the older 1.7 upgrade we can simply use the PRISTINE table to replace the MD5 with the corresponding SHA1 in the bump_to_19 code. The 1.6 upgrade is a bit harder. We can do the text-base to pristine before doing the entries file, so that the PRISTINE table is available, but the table is not currently indexed on MD5. As there is now only one table per wc it might be too slow if there are lots of files. We may need an MD5 index, as part of PRISTINE or separate, just for the duration of the upgrade. The bump_to_19 code can do the MD5 to SHA1 conversion before switching to single-db, the table is smaller and may not need an MD5 index (and the bump_to_19 code simply isn't as important as the 1.6 upgrade code). In the old entries format we only kept one checksum, while we can have two pristine files, so just keeping it as MD5 can't solve all the issues. But we can't just assume that we never see a collision with MD5 over an entire tree.. or we wouldn't have switched to SHA1 in the first place. Maybe we should use a somewhat broader structure then just a single (or dual) svn_wc_entry_t to keep the state while upgrading. This can then contain things like the SHA1 checksums and other values that can't be stored in just the entries. Just looking up a node by its MD5 in the pristines table will not resolve the collision problems :( Bert
Re: merging into locally added files
On Tue, Aug 24, 2010 at 08:59:32AM +0100, Julian Foad wrote: On Tue, 2010-08-24, Stefan Sperling wrote: On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote: You seem to be talking only about the case where the (locally added) target is the root of the whole merge, and saying that lack of ancestral relationship between the source node and this target node doesn't matter. Maybe the user performing the merge is fully aware of what he/she is doing, which is fine in this simple case. But what about the general case, where the modification to a locally added node may be somewhere deep down in a merge that's supposed to be a simple automatic merge? I don't think locally added nodes somewhere deep within the merge target are affected by this change. Those should be handled by the regular tree conflict logic. The change only affects the merge target root, which can now be a locally added file or directory. Previously, Subversion just errored out on locally added merge target roots and didn't merge anything at all. Oh, OK! That makes sense then. I've thought about this a bit more, and am now convinced that there is in fact a use case where your policy distinction makes sense. :) If users do automatic merges, those merges can be pretty complex and could contain several merge steps. At each step, the merge command would be run to merge a change into a root below some logical merge master root. So each individual merge is run with a different root. In this case, users might expect a merge into a locally added node somewhere below the master root to raise a tree conflict, because they may not be able to tell in advance whether a series of merges will end up using an added node as merge target. But this is a very narrow use case, and Subversion behaves far worse in other tree conflict situations (e.g. deleted directory vs. deleted directory is still not recognised). And I would suggest to people who run into this situation and expect a tree conflict to review their branching/merging patterns and simplify them to avoid this situation. Stefan
error on compiling subversion with kwallet support
Hi, I am compiling subversion with kwallet support. But, Getting the following error. ./configure --with-kwallet --prefix=/home/shrinivasan/svn-builds/1.6.13 snip /usr/share/apr-1.0/build/libtool --tag=CXX --silent --mode=compile g++ -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -DQT_SHARED -g -O2 -I./subversion/include -I./subversion -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtDBus -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtGui -I/usr/include -o subversion/libsvn_auth_kwallet/kwallet.lo -c subversion/libsvn_auth_kwallet/kwallet.cpp libtool: ignoring unknown tag CXX cd subversion/libsvn_auth_kwallet /usr/share/apr-1.0/build/libtool --tag=CXX --silent --mode=link g++ -g -O2 -rpath /home/shrinivasan/svn-builds/1.6.13/lib -Wl,--no-undefined -o libsvn_auth_kwallet-1.la kwallet.lo version.lo -lapr-1 -L/lib -ldbus-1 -lpthread -lrt -lQtCore -lQtDBus -lQtGui -lkdecore -lkdeui ../../subversion/libsvn_subr/libsvn_subr-1.la libtool: ignoring unknown tag CXX .libs/kwallet.o: In function `kwallet_password_set': /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:376: undefined reference to `operator new(unsigned int)' /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:376: undefined reference to `operator new(unsigned int)' /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:376: undefined reference to `operator delete(void*)' .libs/kwallet.o: In function `kwallet_password_get': /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:311: undefined reference to `operator new(unsigned int)' /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:311: undefined reference to `operator new(unsigned int)' /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:311: undefined reference to `operator delete(void*)' /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:311: undefined reference to `operator delete(void*)' .libs/kwallet.o: In function `QMapint, unsigned long::detach_helper()': /usr/include/qt4/QtCore/qmap.h:739: undefined reference to `__cxa_begin_catch' /usr/include/qt4/QtCore/qmap.h:741: undefined reference to `__cxa_rethrow' /usr/include/qt4/QtCore/qmap.h:739: undefined reference to `__cxa_end_catch' .libs/kwallet.o:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status make: *** [subversion/libsvn_auth_kwallet/libsvn_auth_kwallet-1.la] Error 1 /snip My environment : Ubuntu 10.04 gcc - 4.4.3 kde-devel : 5:55ubuntu1 Please guide me on compiling with kwallet support. Thanks. -- Regards, Shrinivasan CollabNet Support
Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
Bert Huijben b...@vmoo.com writes: In the old entries format we only kept one checksum, while we can have two pristine files, so just keeping it as MD5 can't solve all the issues. That's NODE_DATA, nothing to do with single-db. But we can't just assume that we never see a collision with MD5 over an entire tree.. or we wouldn't have switched to SHA1 in the first place. Maybe we should use a somewhat broader structure then just a single (or dual) svn_wc_entry_t to keep the state while upgrading. This can then contain things like the SHA1 checksums and other values that can't be stored in just the entries. Just looking up a node by its MD5 in the pristines table will not resolve the collision problems :( Single-db does make MD5 collisions more likely, but is it a real problem? I know it's possible to create MD5 collisions in certain circumstances, but are there any reports of accidental collisions rather than deliberately created ones? If we create the temporary MD5 index during the upgrade then we can probably spot the collision and abort. I think that would be good enough. -- Philip
RE: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
Bert Huijben wrote: Philip Martin wrote: Bert Huijben b...@vmoo.com writes: * subversion/tests/cmdline/upgrade_tests.py (text_base_path): Restore MD5 support removed in r960036. I think the real fix would be to upgrade to SHA1 (and add the mapping in the pristines table) in the upgrade step. I expected that this was already handled? Yes, that needs to happen, and no, it doesn't happen yet. The new code stores SHA1 on checkout/update but the upgrade code simply copies the MD5 and doesn't do MD5 to SHA1 conversion. I discussed this with Julian on IRC yesterday, the plan is to remove the MD5 support eventually. There are two cases to consider, upgrade from 1.6 to latest and upgrade from older 1.7 to latest. For the older 1.7 upgrade we can simply use the PRISTINE table to replace the MD5 with the corresponding SHA1 in the bump_to_19 code. The 1.6 upgrade is a bit harder. We can do the text-base to pristine before doing the entries file, so that the PRISTINE table is available, If, instead, we construct each the PRISTINE table entry at the point where we're converting an entry from the entries file, then we can calculate both checksums on the fly, and we can store both of them in the new DB row(s). That's true even for those few pristines that don't have any checksum in the 'entries' file. Maybe that makes the code flow harder, but it sounds easier than maintaining an intermediate store of checksums. but the table is not currently indexed on MD5. As there is now only one table per wc it might be too slow if there are lots of files. We may need an MD5 index, as part of PRISTINE or separate, just for the duration of the upgrade. *If* we were to use that method (but see below), and *if* it does turn out to be too slow, then adding an index would be an easy change. I don't think we need to hesitate from using MD5 look-ups on that account. The bump_to_19 code can do the MD5 to SHA1 conversion before switching to single-db, the table is smaller and may not need an MD5 index (and the bump_to_19 code simply isn't as important as the 1.6 upgrade code). In the old entries format we only kept one checksum, while we can have two pristine files, so just keeping it as MD5 can't solve all the issues. But we can't just assume that we never see a collision with MD5 over an entire tree.. or we wouldn't have switched to SHA1 in the first place. MD5 collisions during upgrading an existing WC? A remote possibility of course, but yes, let's try to avoid that possibility. If MD5 look-up was the only practical way forward, especially if it were per-directory, then I wouldn't be too concerned about handling collisions gracefully and think we would only need to detect them and bail out with an apologetic message. For upgrades from 1.7-dev versions, I think we should be happy to accept the possibility of MD5 collisions. Maybe we should use a somewhat broader structure then just a single (or dual) svn_wc_entry_t to keep the state while upgrading. This can then contain things like the SHA1 checksums and other values that can't be stored in just the entries. That sounds harder than transferring the pristines in-line, though I'm not sure. - Julian
Re: error on compiling subversion with kwallet support
shrinivasan shriniva...@collab.net writes: I am compiling subversion with kwallet support. But, Getting the following error. ./configure --with-kwallet --prefix=/home/shrinivasan/svn-builds/1.6.13 cd subversion/libsvn_auth_kwallet /usr/share/apr-1.0/build/libtool --tag=CXX --silent --mode=link g++ -g -O2 -rpath /home/shrinivasan/svn-builds/1.6.13/lib -Wl,--no-undefined -o libsvn_auth_kwallet-1.la kwallet.lo version.lo -lapr-1 -L/lib -ldbus-1 -lpthread -lrt -lQtCore -lQtDBus -lQtGui -lkdecore -lkdeui ../../subversion/libsvn_subr/libsvn_subr-1.la libtool: ignoring unknown tag CXX .libs/kwallet.o: In function `kwallet_password_set': /home/shrinivasan/svn/subversion/subversion/libsvn_auth_kwallet/kwallet.cpp:376: undefined reference to `operator new(unsigned int)' Are you building 1.6 or trunk? I see 1.6.13 but I also see APR's libtool being used and you don't mention --experimental-libtool. For trunk try --with-custom-libtool='/bin/bash /usr/bin/libtool' For 1.6 try --disable-experimental-libtool -- Philip
Re: Disable diff-cmd
On Tue, Aug 24, 2010 at 11:35 AM, Martin Furter m...@rola.ch wrote: --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. Why not to stop proliferation of options by allowing an empty value for --diff-cmd to be treated as an instructions to use internal implementation? This looks like a bug that can be fixed in 1.6 series as well. Please, CC. -- anatoly t.
Re: RFC: How should Subversion handle OS-deleted paths?
On Fri, 2010-08-20, Paul Burba wrote: I think we can all agree that when a user deletes part of their WC via the OS they have made a mistake of some sort. But which mistake exactly? The obvious answer is that they really intended 'svn del dirX/foo.c'. But possibly they intended something more akin to 'svn up --set-depth empty dirX'. Or maybe it was just a true mistake, and nothing was intended; they expect foo.c to be there! Or maybe the user *renamed* or *moved* the item to a different path, where it still exists complete with its local mods, and when the user realizes they should have used svn mv instead, they will want to issue the as-yet-unavailable svn mv --retrospectively command [1], or, failing that, they will want to move the item back into place and then issue the correct svn mv. So there are several courses of action that the user might want. Is there an obvious, simple and safe default action that Subversion could take in order to resolve each missing item it encounters? I think there isn't. I originally came to this question when dealing with merge tracking and paths missing because they were deleted outside of Subversion, see http://svn.haxx.se/dev/archive-2010-08/0156.shtml. Somewhat tardily I realized the *first* question to be answered is not how merge tracking should deal with such paths, but how should Subversion in general deal with them. I see a few basic approaches: 1) Consistent Approach -- Restore the Missing Paths (unless there is really a compelling reason not too, but the default approach is to restore) WCNG's single DB allows us to simply restore these missing paths as we encounter them (the notable exception being 'svn st' of course, which just reports the missing state). For a file, the working properties (stored in ACTUAL_NODE table) are still known to Subversion, whereas its working text is NOT known to Subversion. So Subversion could restore the item by: * reverting the file text and keeping the working properties, or * reverting the file text and reverting the properties. For a directory, that applies to each versioned file inside it, as well as to the properties on the directories themselves. (Any unversioned items inside it would of course be lost.) Is either of those ways obviously the right way to restore? I would suggest neither is obviously the right one. Exhibit A of this behavior: In 1.6.x and 1.7 in multiple DB mode, svn revert skips missing directories. In single-DB mode they are restored. Here, they are restored in the second sense above - i.e. reverted. 2) Consistent Approach: Error out If we detect missing paths, simply throw an error asking that the user restore them before proceeding. Obviously for svn st/up/revert, the current behavior is fine, but for svn ci/sw/merge we could follow this route. I think this is a good approach for ci/sw/merge and in fact most commands. It is the simplest approach and that counts for a lot. 3) Case-by-Case Approach: Maybe there is *no* consistent approach, and sometimes we will want to restore, but other times we'll do something else. I'll leave what something else is as an open question for the moment. I think consistency is important, but I'm not seeing a single behaviour that's suitable for all commands. Let me see... svn revert should of course restore any missing thing back to its last versioned state, because that's it's job. (In 1.6 and earlier, it was unable to restore missing directories, which was always known as a deficiency.) svn status should of course report the problem, because that's its job. svn delete could throw an error, or it could ignore the inconsistency and just schedule the thing for deletion anyway. (I suppose we could consider the latter behaviour to be first restoring and then deleting, in one operation.) Same for any other UI that's able to make the node go away such as svn up --set-depth empty PARENT_PATH. svn diff and svn blame I think should throw an error if trying to access the missing text of the node. (Same for svn cat -rWORKING if we ever support that.) I don't see any good reason for read-only commands such as these to attempt to fix a problem. svn copy and svn move where the source is missing: throw an error. They could perhaps alternatively perform a copy or move in which the target working file/dir is still missing, but that's greater complexity and I see no benefit. svn export: throw an error. It could perhaps alternatively skip the missing node, on the basis that its job is to re-create the current working state of the WC, but I think we can define 'missing' as an invalid (unacceptable) state. svn cleanup: throw an error if it needs to access the missing working version, else no effect. I would say update's auto-restoring behaviour is a historical wart. I think it was for compatibility with CVS. I won't try to argue that we should change it now. The pattern that's emerging from my
Re: Disable diff-cmd
On Tue, Aug 24, 2010 at 02:24:25PM +0300, anatoly techtonik wrote: On Tue, Aug 24, 2010 at 11:35 AM, Martin Furter m...@rola.ch wrote: --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. Why not to stop proliferation of options by allowing an empty value for --diff-cmd to be treated as an instructions to use internal implementation? Boils down to personal preference. See http://svn.haxx.se/dev/archive-2010-05/0456.shtml This looks like a bug that can be fixed in 1.6 series as well. If there is strong demand for backporting the --internal-diff option I guess we could do it. But is using --config-dir an acceptable workaround for now? Stefan
RE: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
-Original Message- From: Julian Foad [mailto:julian.f...@wandisco.com] Sent: dinsdag 24 augustus 2010 13:04 To: Bert Huijben Cc: 'Philip Martin'; dev@subversion.apache.org Subject: RE: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py Bert Huijben wrote: Philip Martin wrote: Bert Huijben b...@vmoo.com writes: * subversion/tests/cmdline/upgrade_tests.py (text_base_path): Restore MD5 support removed in r960036. I think the real fix would be to upgrade to SHA1 (and add the mapping in the pristines table) in the upgrade step. I expected that this was already handled? Yes, that needs to happen, and no, it doesn't happen yet. The new code stores SHA1 on checkout/update but the upgrade code simply copies the MD5 and doesn't do MD5 to SHA1 conversion. I discussed this with Julian on IRC yesterday, the plan is to remove the MD5 support eventually. There are two cases to consider, upgrade from 1.6 to latest and upgrade from older 1.7 to latest. For the older 1.7 upgrade we can simply use the PRISTINE table to replace the MD5 with the corresponding SHA1 in the bump_to_19 code. The 1.6 upgrade is a bit harder. We can do the text-base to pristine before doing the entries file, so that the PRISTINE table is available, If, instead, we construct each the PRISTINE table entry at the point where we're converting an entry from the entries file, then we can calculate both checksums on the fly, and we can store both of them in the new DB row(s). That's true even for those few pristines that don't have any checksum in the 'entries' file. 1.0.0 working copies have no checksums at all if I remembered correctly and we certainly have to upgrade those WCs. Same recipe for all files with a revert base. Maybe that makes the code flow harder, but it sounds easier than maintaining an intermediate store of checksums. but the table is not currently indexed on MD5. As there is now only one table per wc it might be too slow if there are lots of files. We may need an MD5 index, as part of PRISTINE or separate, just for the duration of the upgrade. *If* we were to use that method (but see below), and *if* it does turn out to be too slow, then adding an index would be an easy change. I don't think we need to hesitate from using MD5 look-ups on that account. The bump_to_19 code can do the MD5 to SHA1 conversion before switching to single-db, the table is smaller and may not need an MD5 index (and the bump_to_19 code simply isn't as important as the 1.6 upgrade code). In the old entries format we only kept one checksum, while we can have two pristine files, so just keeping it as MD5 can't solve all the issues. But we can't just assume that we never see a collision with MD5 over an entire tree.. or we wouldn't have switched to SHA1 in the first place. MD5 collisions during upgrading an existing WC? A remote possibility of course, but yes, let's try to avoid that possibility. If MD5 look-up was the only practical way forward, especially if it were per-directory, then I wouldn't be too concerned about handling collisions gracefully and think we would only need to detect them and bail out with an apologetic message. For upgrades from 1.7-dev versions, I think we should be happy to accept the possibility of MD5 collisions. For dev versions no problem, but from upgrades below from format 12 (=last entries files version) or older we should/must do the right thing. (See the other mail: Just make the intermediate versions use the python script. These users knew that this was an option when they started using trunk) Bert
Re: Disable diff-cmd
On Tue, Aug 24, 2010 at 2:29 PM, Stefan Sperling s...@elego.de wrote: --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. Why not to stop proliferation of options by allowing an empty value for --diff-cmd to be treated as an instructions to use internal implementation? Boils down to personal preference. See http://svn.haxx.se/dev/archive-2010-05/0456.shtml I believe Git has --no-ext-diff option for that purpose, but I still think that universal ability to reset option to default with `--diff-cmd=` or `--config-option config:helpers:diff-cmd=` is a better approach, because it will also allow to use default values for other cmd options like editor-cmd, diff3-cmd, merge-tool-cmd and ssh. This looks like a bug that can be fixed in 1.6 series as well. If there is strong demand for backporting the --internal-diff option I guess we could do it. But is using --config-dir an acceptable workaround for now? Not really. In Rietveld project we call svn diff by upload.py script used to send diffs for review to remote server. We can't instruct users to copy config dir, so we need to do this automatically. That means copying the whole config dir and comment only one option just for the sake of running svn diff Copying is required, because there are some options that may affect svn diff output. Some options may even be specified in windows registry. Extracting them from there is an overkill. That's why a simple solution with one option override at a time is better. Having --internal-diff option backported will allow us to detect if an external diff tool is used and advise users to upgrade to a newer 1.6 Subversion instead of implementing config dir copy and override logic. Not many will be ready to switch to 1.7 and I doubt that it will appear in Debian backports any time soon. http://code.google.com/p/rietveld/issues/detail?id=217 Please, CC. -- anatoly t.
Re: Disable diff-cmd
anatoly techtonik techto...@gmail.com writes: Not really. In Rietveld project we call svn diff by upload.py script used to send diffs for review to remote server. We can't instruct users to copy config dir, so we need to do this automatically. That means copying the whole config dir and comment only one option just for the sake of running svn diff I suppose you could use the Python bindings and bypass the command line client. Then the script would have full control. -- Philip
Re: Disable diff-cmd
anatoly techtonik wrote: On Tue, Aug 24, 2010 at 2:29 PM, Stefan Sperling s...@elego.de wrote: --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. Why not to stop proliferation of options by allowing an empty value for --diff-cmd to be treated as an instructions to use internal implementation? Boils down to personal preference. See http://svn.haxx.se/dev/archive-2010-05/0456.shtml I believe Git has --no-ext-diff option for that purpose, but I still Let's rename --internal-diff to --no-ext-diff, just for ease of memory for those who use both Svn and Git. think that universal ability to reset option to default with `--diff-cmd=` or `--config-option config:helpers:diff-cmd=` is a better approach, because it will also allow to use default values for other cmd options like editor-cmd, diff3-cmd, merge-tool-cmd and ssh. You know what? I like that reasoning. We could still have a --internal-diff (or --no-ext-diff) for user-friendliness reasons, but define it as an alias for --diff-cmd=''. That would have the advantage of making clear how those two options would interact if both are specified. - Julian
Re: Disable diff-cmd
Philip Martin philip.mar...@wandisco.com writes: anatoly techtonik techto...@gmail.com writes: Not really. In Rietveld project we call svn diff by upload.py script used to send diffs for review to remote server. We can't instruct users to copy config dir, so we need to do this automatically. That means copying the whole config dir and comment only one option just for the sake of running svn diff I suppose you could use the Python bindings and bypass the command line client. Then the script would have full control. Another thing you could do is explicitly invoke an external diff to override any user default. -- Philip
Re: Disable diff-cmd
On Tue, Aug 24, 2010 at 01:48:43PM +0100, Julian Foad wrote: anatoly techtonik wrote: On Tue, Aug 24, 2010 at 2:29 PM, Stefan Sperling s...@elego.de wrote: --internal-diff seems to be new in 1.7 so i guess the only option is using --config-dir to override it. Why not to stop proliferation of options by allowing an empty value for --diff-cmd to be treated as an instructions to use internal implementation? Boils down to personal preference. See http://svn.haxx.se/dev/archive-2010-05/0456.shtml I believe Git has --no-ext-diff option for that purpose, but I still Let's rename --internal-diff to --no-ext-diff, just for ease of memory for those who use both Svn and Git. think that universal ability to reset option to default with `--diff-cmd=` or `--config-option config:helpers:diff-cmd=` is a better approach, because it will also allow to use default values for other cmd options like editor-cmd, diff3-cmd, merge-tool-cmd and ssh. You know what? I like that reasoning. We could still have a --internal-diff (or --no-ext-diff) for user-friendliness reasons, but define it as an alias for --diff-cmd=''. That would have the advantage of making clear how those two options would interact if both are specified. All fine with me. Stefan
Re: Commiting, tree conflicts and keep-local
I'm looking at the tree_conflict_tests.py 17 failure in single-DB. FAIL: tree_conflict_tests.py 17: --keep-local del on dir with TCs inside Neels, you might be able to shed some light on this. What's the test for? The test says: if you have a directory with tree conflicts inside it, you should be able to delete that directory (with the --keep-local flag) and then commit the result, without having to resolve the tree conflicts as an explicit step. I'm not sure if that is really desired behaviour any more. AFAIK, the intention is that the user must always resolve conflicts before committing. But the steps it goes through are odd. It first schedules the dir for deletion, but leaving tree conflicts visible inside it, like Philip observed back in May (see quoted msg below). Then it tries to commit that delete-a-directory-with-conflicts-inside, which definitely seems wrong, even if it worked in 1.6. And why is the --keep-local command-line flag involved? I see no logical reason why that should make a difference. I wonder if the test is just preserving historical but unwanted behaviour. What happens in multi-DB mode? -- The svn delete --keep-local marks the directory as to-be-deleted and sets the keep_local flag in the DB, to tell the post-commit processing not to remove the directory after committing its deletion. So far so good. But it leaves the directory's children marked as conflicted, which shows up in status: [[[ $ svn status D 3 3 jrandom A/C ? C A/C/file local edit, incoming delete upon update ? C A/C/dir local edit, incoming delete upon update ]]] At commit time, harvest_committables() says: if (! keep_local) SVN_ERR(bail_on_tree_conflicted_children(..., local_abspath, db_kind, ...)); Thus it doesn't check for conflicted children, and the commit goes ahead. In commit post-processing, the directory is left on disk but its metadata is all removed so it no longer has any conflicts recorded in it. What happens in single-DB mode? --- The same, except that no keep_local flag is stored in the DB, and when harvest_committables() tries to read it back it sees FALSE. Thus harvest_committables() DOES call bail_on_tree_conflicted_children() and the commit fails because there are tree-conflicted children. What should happen? --- I think the required changes are: * Commit should unconditionally bail out if there are any conflicts inside a node being committed. No more testing the 'keep_local' flag at this stage. * Either the regression test should call svn resolved before attempting the commit, or the svn delete that it performs should clear the conflicts from inside the directory that it deleted. * None of this behaviour should depend on whether the user wants an unversioned copy of the node to be kept on disk. Neels, in the IRC log below it looks like you had a patch for making svn delete clear tree conflicts when --force or --keep-local is given. I don't see why we'd want --keep-local to behave specially, but with --force, sure, that should clear conflicts. Do you still have the patch? (The paste linked from IRC has expired.) http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-05-06#l44 - Julian On Wed, 2010-05-12, Greg Stein wrote: Temp function. It can be used in entries.c, too. It'll only last until single-db. Not blasting conflict info is good, in case of reverts. On May 12, 2010 2:17 PM, Philip Martin philip.mar...@wandisco.com wrote: The only thing keeping me from finally removing svn_wc_entry_t from harvest_committables is keep_local. There was some discussion on IRC a few days ago http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-05-06#l44 but it really resolve things. It includes pointers to Neels patch to make keep-local remove tree conflicts. Tree conflicts generally prevent a commit, however if the conflict is inside a directory that has been deleted with svn rm --keep-local then the commit will be allowed. So rm -rf repo wc svnadmin create repo svn mkdir -mm file://`pwd`/repo/A svn mkdir -mm file://`pwd`/repo/A/B svn co -r1 file://`pwd`/repo wc svn cp file://`pwd`/repo/A wc/A/B svn up wc # creates tree conflict for A/B svn ci -mm wc # fails because of tree conflict svn rm wc/foo # fails because of tree conflict svn rm --keep-local wc/A # succeeds svn ci -mm wc # succeeds When A is rm'd the tree conflict is sort of still present, it shows up in status, but it's all a bit dodgy. After the commit the unversioned directory A/B still contains a .svn directory. If I revert, rather than commit, then wc/A/B becomes unversioned. In wc-metadata.sql there is a comment about
Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
Bert Huijben b...@qqmail.nl writes: -Original Message- From: Julian Foad [mailto:julian.f...@wandisco.com] If, instead, we construct each the PRISTINE table entry at the point where we're converting an entry from the entries file, then we can calculate both checksums on the fly, and we can store both of them in the new DB row(s). That's true even for those few pristines that don't have any checksum in the 'entries' file. Or we could modify the current code that constructs the pristine table to update the base/working nodes as well. 1.0.0 working copies have no checksums at all if I remembered correctly and we certainly have to upgrade those WCs. Same recipe for all files with a revert base. Well, upgrade_tests 7 (basic_upgrade_1_0) passes in single-db and it verifies the pristine text post-upgrade using MD5. When I look in the tarball I see checksums in the entries file. Revert bases won't have a checksum, but until we have NODE_DATA there is nowhere to put a revert base checksum. -- Philip
RE: svn commit: r988550 - in /subversion/trunk/subversion: libsvn_wc/entries.c tests/cmdline/upgrade_tests.py
-Original Message- From: phi...@apache.org [mailto:phi...@apache.org] Sent: dinsdag 24 augustus 2010 16:13 To: comm...@subversion.apache.org Subject: svn commit: r988550 - in /subversion/trunk/subversion: libsvn_wc/entries.c tests/cmdline/upgrade_tests.py Author: philip Date: Tue Aug 24 14:13:26 2010 New Revision: 988550 URL: http://svn.apache.org/viewvc?rev=988550view=rev Log: Fix upgrade_tests.py 7 in single-db. * subversion/libsvn_wc/entries.c (insert_working_node): Don't force kind to subdir. (write_entry): Make working_node subdirs incomplete initially. How are you going to handle not present but added subdirectories in this way? You only have one status field for BASE_NODE and not present is only recorded in the parent directories (in the entries world recorded as entry-deleted in the parent dir). But if you set the directory to incomplete the 'not-present' status gets lost. And this can't be fixed from the directory itself, as it doesn't know that it originally existed as not-present, because we only started propagating this information into the subdir in the WC-NG work. Bert
Re: svn commit: r988550 - in /subversion/trunk/subversion: libsvn_wc/entries.c tests/cmdline/upgrade_tests.py
Bert Huijben b...@qqmail.nl writes: -Original Message- From: phi...@apache.org [mailto:phi...@apache.org] Sent: dinsdag 24 augustus 2010 16:13 To: comm...@subversion.apache.org Subject: svn commit: r988550 - in /subversion/trunk/subversion: libsvn_wc/entries.c tests/cmdline/upgrade_tests.py Author: philip Date: Tue Aug 24 14:13:26 2010 New Revision: 988550 URL: http://svn.apache.org/viewvc?rev=988550view=rev Log: Fix upgrade_tests.py 7 in single-db. * subversion/libsvn_wc/entries.c (insert_working_node): Don't force kind to subdir. (write_entry): Make working_node subdirs incomplete initially. How are you going to handle not present but added subdirectories in this way? Do you mean $ svn rm wc/A $ svn ci -mm wc # wc/A is not-present $ svn mkdir wc/A $ svn upgrade wc I get $ sqlite3 wc/.svn/wc.db select * from base_node 1||1|||normal|dir|1|||1|1282662995630871|pm|infinity||0 1|A|1|A||not-present|dir|-1||infinity||0 $ sqlite3 wc/.svn/wc.db select * from working_node 1|A||normal|dir||infinity|||0||0 which I think is correct. Or do you mean $ svn mkdir wc/A $ rm -rf wc/A $ svn upgrade wc I get $ sqlite3 wc/.svn/wc.db select * from base_node 1||1|||normal|dir|0|||0|1282663366673755||infinity||0 $ sqlite3 wc/.svn/wc.db select * from working_node 1|A||incomplete|dir||infinity|||0||0 I don't think there is any Subversion command to fix the working=incomplete at present. I suppose the user could revert and do another mkdir. You only have one status field for BASE_NODE and not present is only recorded in the parent directories (in the entries world recorded as entry-deleted in the parent dir). But if you set the directory to incomplete the 'not-present' status gets lost. And this can't be fixed from the directory itself, as it doesn't know that it originally existed as not-present, because we only started propagating this information into the subdir in the WC-NG work. -- Philip
Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py
Bert Huijben b...@qqmail.nl writes: From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: dinsdag 24 augustus 2010 16:58 To: Bert Huijben Cc: 'Julian Foad'; 'Bert Huijben'; dev@subversion.apache.org Subject: Re: svn commit: r988074 - in /subversion/trunk/subversion/tests/cmdline: svntest/wc.py upgrade_tests.py Bert Huijben b...@qqmail.nl writes: -Original Message- From: Julian Foad [mailto:julian.f...@wandisco.com] If, instead, we construct each the PRISTINE table entry at the point where we're converting an entry from the entries file, then we can calculate both checksums on the fly, and we can store both of them in the new DB row(s). That's true even for those few pristines that don't have any checksum in the 'entries' file. Or we could modify the current code that constructs the pristine table to update the base/working nodes as well. 1.0.0 working copies have no checksums at all if I remembered correctly and we certainly have to upgrade those WCs. Same recipe for all files with a revert base. Well, upgrade_tests 7 (basic_upgrade_1_0) passes in single-db and it verifies the pristine text post-upgrade using MD5. When I look in the tarball I see checksums in the entries file. Revert bases won't have a checksum, but until we have NODE_DATA there is nowhere to put a revert base checksum. Sure there is. If you have a normal replaced file you can have one checksum in BASE_NODE (for the original) and one in WORKING_NODE (for the copy that replaced the original). Only when you delete that working node, you have no place to store it if that copy happens to be the child of the real copy. Ah yes, of course. That's one of the things we could fix by updating base/working while construction pristine. We need lots more upgrade regression tests. -- Philip
Re: Disable diff-cmd
On Tue, Aug 24, 2010 at 3:48 PM, Philip Martin philip.mar...@wandisco.com wrote: Not really. In Rietveld project we call svn diff by upload.py script used to send diffs for review to remote server. We can't instruct users to copy config dir, so we need to do this automatically. That means copying the whole config dir and comment only one option just for the sake of running svn diff I suppose you could use the Python bindings and bypass the command line client. Then the script would have full control. upload.py helper script is aimed to be used by the end users (developers) from a fresh checkout of a project. The project itself may not use Python at all. Having a requirement to install Subversion bindings besides Python would be an overkill. From my experience installing Subversion Python bindings is not a trivial task. You need to be careful about exact Python/Subversion versions and be aware about installation procedure for your platform. Matters are complicated by the fact that there seems to be several different bindings in the wild. If I remember correctly only `ctypes` bindings can work with multiple version of Python, but I can't recall that Subversion installer proposed to install them, and do not remember seeing any standalone distributions. Philip Martin philip.mar...@wandisco.com wrote: Another thing you could do is explicitly invoke an external diff to override any user default. That could be a solution if only `diff` was available on Windows by default, but it's not. Please, CC. -- anatoly t.
git diff format support
Hello again, I am struggling with svn diff output format, which doesn't contain information about added, copied and renamed files. This information is needed for generating complete code review diffs for Rietveld project. It would be nice if `svn diff` supported additional -g, --git option to generate output that contains this info - http://mercurial.selenic.com/wiki/GitExtendedDiffFormat Please, CC. -- anatoly t.
RE: git diff format support
Hi, There is a --git-diff option in Subversion Trunk, so this will probably be available in Subversion 1.7. Kind regards, Jon -Original Message- From: anatoly techtonik [mailto:techto...@gmail.com] Sent: 24 August 2010 17:35 To: Subversion Development Subject: git diff format support Hello again, I am struggling with svn diff output format, which doesn't contain information about added, copied and renamed files. This information is needed for generating complete code review diffs for Rietveld project. It would be nice if `svn diff` supported additional -g, --git option to generate output that contains this info - http://mercurial.selenic.com/wiki/GitExtendedDiffFormat Please, CC. -- anatoly t. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: git diff format support
Good to know. Is it worth to rename it to `svn diff --git` for unification with Mercurial? Please, CC. On Tue, Aug 24, 2010 at 7:44 PM, Jon Foster jon.fos...@cabot.co.uk wrote: Hi, There is a --git-diff option in Subversion Trunk, so this will probably be available in Subversion 1.7. Kind regards, Jon -Original Message- From: anatoly techtonik [mailto:techto...@gmail.com] Sent: 24 August 2010 17:35 To: Subversion Development Subject: git diff format support Hello again, I am struggling with svn diff output format, which doesn't contain information about added, copied and renamed files. This information is needed for generating complete code review diffs for Rietveld project. It would be nice if `svn diff` supported additional -g, --git option to generate output that contains this info - http://mercurial.selenic.com/wiki/GitExtendedDiffFormat Please, CC. -- anatoly t. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: RFC: How should Subversion handle OS-deleted paths?
On Tue, 24 Aug 2010, Julian Foad wrote: the as-yet-unavailable svn mv --retrospectively command [1], Is this is just a special case of the as-yet-unavailable --metadata-only option, which would tell svn to adjust its metadata as if some operation were performed, but not to touch anything outside the .svn directory (or wherever metadata is kept)? --apb (Alan Barrett)
Re: git diff format support
On Tue, Aug 24, 2010 at 05:44:50PM +0100, Jon Foster wrote: Hi, There is a --git-diff option in Subversion Trunk, so this will probably be available in Subversion 1.7. Yes. But there are some restrictions, most notably with renames. Our git-style diffs show adds, deletes, and copies properly. But renames are shown as copy+delete, just like elsewhere in Subversion. See the example below. We'll need better rename support to improve this. It's anticipated that at least local renames (i.e. in the working copy) will be recognized as renames rather than copy+delete in Subversion 1.8. Stefan $ svn cp alpha alpha2 A alpha2 $ svn mv beta beta2 A beta2 D beta $ svn diff --git-diff --show-copies-as-adds Index: alpha2 === diff --git a/alpha2 b/trunk/alpha copy from alpha2 copy to trunk/alpha --- a/alpha2(revision 0) +++ b/alpha2(working copy) @@ -0,0 +1 @@ +alpha Index: beta === diff --git a/beta b/beta deleted file mode 10644 --- a/beta (revision 2) +++ /dev/null (working copy) @@ -1 +0,0 @@ -beta Index: beta2 === diff --git a/beta2 b/trunk/beta copy from beta2 copy to trunk/beta --- a/beta2 (revision 0) +++ b/beta2 (working copy) @@ -0,0 +1 @@ +beta
Re: git diff format support
On Tue, Aug 24, 2010 at 07:51:28PM +0300, anatoly techtonik wrote: Good to know. Is it worth to rename it to `svn diff --git` for unification with Mercurial? I suppose we could rename the option to --git, yes. Do you want to send a patch that does so? See http://subversion.apache.org/docs/community-guide/general.html#patches Thanks, Stefan
About character encoding of the text files
Hello, This is my first post in this list. I was pointed to post here in another thread ViewVC site (http://viewvc.tigris.org/issues/show_bug.cgi?id=11). The original reason was that ViewVC is unable to show correctly text files that contain Cyrillic characters (character set windows-1251). (The same issue is related for Western Europe's characters too.) People told me that ViewVC cannot do this because it lacks of encoding information. This information should come from Subversion and Subversion could have this information if the users have supplied it into Subversion. The last posts in above mentioned thread give more information about the problem. As I understood, information about character encoding may be supplied as svn: property, say, svn:encoding encoding_type. Par example: svn:encoding windows-1251. So, are there any intentions among the Subversion developers and users to be defined such property? Would it be reliable way for this task? If there is an issue about this problem, what is its priority? -- Regards, Ivan Cenov OKTO-7 Co., Botevgrad, Bulgaria i_ce...@botevgrad.com, i...@okto7.com GSM: +359 888 76 10 80 phone: +359 723 6 61 20, +359 723 6 61 61 fax: +359 723 6 62 62
Re: About character encoding of the text files
On Tue, Aug 24, 2010 at 21:19, Ivan Cenov i_ce...@botevgrad.com wrote: Hello, This is my first post in this list. I was pointed to post here in another thread ViewVC site (http://viewvc.tigris.org/issues/show_bug.cgi?id=11). The original reason was that ViewVC is unable to show correctly text files that contain Cyrillic characters (character set windows-1251). (The same issue is related for Western Europe's characters too.) People told me that ViewVC cannot do this because it lacks of encoding information. This information should come from Subversion and Subversion could have this information if the users have supplied it into Subversion. The last posts in above mentioned thread give more information about the problem. As I understood, information about character encoding may be supplied as svn: property, say, svn:encoding encoding_type. Par example: svn:encoding windows-1251. So, are there any intentions among the Subversion developers and users to be defined such property? Would it be reliable way for this task? If there is an issue about this problem, what is its priority? The property svn:mime-type carries charset information as an additional field: $ svn propset svn:mime-type text/plain;charset=Windows-1251 file1.txt file2.txt ... // ben
