Re: [RFC] mtime functional specification notes
Philipp Marek wrote: On Montag, 21. Dezember 2009, Branko Čibej wrote: Edmund Wong wrote: The patch is attached to this one. Thanks Phlip! Apparently you're having trouble sending patches, because nothing came through again. Do you have an outgoing mail filter, perhaps? I don't believe Apache mail servers drop attachments Well, in my private mail the patch came through. Hi Philipp, Sorry for the delay in response. + property. The format of the property value is '-MM-DD HH:MM:SS' + of which the time is UTC. Please make that conform to the meta-data branch, and use the notation 2009-12-11T23:26:08.123131 which includes sub-seconds, too, so that users won't complain that this information is lost, although their filesystem can store nanoseconds! (And TBH I think that the relative ordering of file-writes is important in some cases, too.) I did not know that one can store nanoseconds. + o if x = dir, then recurisvely f_import(x) typing error, multiple times. Easily fixable. :) commit: +3) R(x) = M(x) In the other lines you had a Set, too. export: + 2) Is S(x) == NULL? + Yes: Set the current M(x) as the file's + mod time. Why wouldn't you use R(x)? And if there's no stored information, there's no need to modify that anyway, as the OS will just use the current time anyway. And similar for checkout. Yes. After reading Philip's post and your post, it makes zero sense to be setting the mtimes. + With the different mtime representations due to the different + platforms and locales Subversion runs on, it gets tricky in having + a unified mtime representation. I don't understand you here. Of course, the properties must be stored in some clearly defined format, and without any locale data interfering - see my note above. Here is where I admit I feel like a quick hack. Of course there must be a clearly defined format. I acknowledge the idea behind the other properties; but if there's a quick way to get the first revision of a node, it's easy to get the mtime data of this revision, too; so there may not be such a big need for the other properties. True. I figured that if users wanted a mtime, they certainly might want to also know when it (file or directory) was first added or committed or imported. Of course, with your definitions A,C,I are the *action* timestamps and have nothing to do with the entry itself; so if you add/commit a big tree structure, you'll have a big set of identical values in there. That's definitely true. Perhaps (possibly a quick thought hack) if during an Add, a commit or an import, the directory's contents are also included (unless specified in ignore item) so would an add-mtime, commit-mtime or import-mtime be set on the directory and it applies to its contents? Further additional files or subdirectories have their mtimes added in the usual fashion. (Am I making any sense here?) BTW, the C is already available as revision timestamp, isn't it? Point well taken. I think that they'd just increase the space needed for the repository unnecessarily; in my commits many files are touched, and with FSFS the properties are fully stored, not deltified. Well, it was my thought that the users might want statistical information on the original add, commit, import, merge, etc.. mtimes on their files/directories. Thanks for the comments. Edmund
Re: [PATCH] v2: Simplify running specific tests on Windows
On Wed, 2009-12-09, Chris Foote wrote:
I have incorporated both of Bert and Daniels suggestions into the
patch (attached).
Thanks Chris. Functionally it looks good. Just some mainly cosmetic
comments below. (One's actually bug but evidently in a bit of code that
doesn't matter much in practice.)
I can make those changes myself and commit it if you like. Would that be
OK?
This version of the patch adds the ability to specify one or more
tests (and test numbers) to run on Windows.
The --test option takes the name of the test executable (with or
without the -test.exe/_tests.py part). It can also take test
number(s) to be run in those tests by appending #NUM to the test
name.
e.g. win-tests.py --release --test=basic_tests.py -t client
win-tests.py --release --test=basic_tests.py#4 -t client#2,4-6
Regards
Chris
[[[
Make it easy to (re)run specific tests on windows by adding a --test/-t
option. The tests can also specify specific test number(s) to run.
* win-tests.py
(_usage_exit): Add the --test/-t option to the help.
(tests_to_run): New. List of tests to be run by the TestHarness.
* build/run_tests.py
(_run_test): Break the progname at a '#' and use the rhs as a list of
test numbers to run.
]]]
Index: win-tests.py
===
--- win-tests.py(revision 888785)
+++ win-tests.py(working copy)
@@ -61,6 +61,9 @@
print( -v, --verbose : talk more)
print( -f, --fs-type=type : filesystem type to use (fsfs is
default))
print( -c, --cleanup : cleanup after running a test)
+ print( -t, --test=TEST: Run the TEST test (all is default); use)
+ print( TEST#n to run a particular test number,)
+ print( multiples also accepted e.g. '2,4-7')
print( --svnserve-args=list : comma-separated list of arguments for)
print( svnserve)
@@ -107,9 +110,9 @@
dll_basename = section.name + - + str(gen_obj.version) + .dll
svn_dlls.append(os.path.join(subversion, section.name, dll_basename))
-opts, args = my_getopt(sys.argv[1:], 'hrdvcpu:f:',
- ['release', 'debug', 'verbose', 'cleanup', 'url=',
-'svnserve-args=', 'fs-type=', 'asp.net-hack',
+opts, args = my_getopt(sys.argv[1:], 'hrdvct:pu:f:',
+ ['release', 'debug', 'verbose', 'cleanup', 'test=',
+'url=', 'svnserve-args=', 'fs-type=', 'asp.net-hack',
'httpd-dir=', 'httpd-port=', 'httpd-daemon',
'httpd-server', 'http-library=', 'help',
'fsfs-packing', 'fsfs-sharding=',
@@ -137,6 +140,7 @@
fsfs_packing = None
server_minor_version = None
config_file = None
+tests_to_run = []
for opt, val in opts:
if opt in ('-h', '--help'):
@@ -149,6 +153,8 @@
verbose = 1
elif opt in ('-c', '--cleanup'):
cleanup = 1
+ elif opt in ('-t', '--test'):
+tests_to_run.append(val)
elif opt in ['-r', '--release']:
objdir = 'Release'
elif opt in ['-d', '--debug']:
@@ -599,6 +605,31 @@
if daemon:
daemon.start()
+# If selected tests specified, only run them
The block of code introduced by this comment is not deciding which tests
to run, it is finding the full path and filename to any tests that were
specified as just a base name. (It took me a little while to read
through it and discover that, which shows how helpful a comment could
be.) So maybe:
# Find the full path and filename of any test that is specified just by
its base name.
+if len(tests_to_run) != 0:
+ tests = []
+ for t in tests_to_run:
+tns = None
+if '#' in t:
+ t, tns = t.split('#')
+
+test = [x for x in all_tests if x.split('/')[-1] == t]
+if not test and (len(t) 9 or
+ (t[-9] != '-test.exe' and t[-9] != '_tests.py')):
That t[-9] != ... will always be true. I think you meant t[-9:] !
= But why not lose all the 9s and just write
if not test and not t.endswith('-test.exe') and not
t.endswith('_tests.py'):
instead?
+ test = [x for x in all_tests if x.split('/')[-1][:-9] == t]
I can't think of a really simple way to lose the -9 here, so comment
it:
# The lengths of '-test.exe' and of '_tests.py' are both 9.
+
+if not test:
+ print(Skipping test '%s', test not found. % t)
+elif tns:
+ tests.append('%s#%s' % (test[0], tns))
+else:
+ tests.extend(test)
+
+ tests_to_run = tests
+else:
+ tests_to_run = all_tests
+
+
print('Testing %s configuration on %s' % (objdir, repo_loc))
sys.path.insert(0, os.path.join(abs_srcdir, 'build'))
import run_tests
@@ -612,7 +643,7 @@
old_cwd = os.getcwd()
try:
os.chdir(abs_builddir)
- failed = th.run(all_tests)
+ failed = th.run(tests_to_run)
except:
os.chdir(old_cwd)
Re: 1.6.7 up for signing/testing
On Wed, Dec 23, 2009 at 10:35 AM, Hyrum K. Wright hyrum_wri...@mail.utexas.edu wrote: A little late, but never never, here's the promised tarballs for Subversion 1.6.7. The magic revision is r893529, and you can find the tarballs here: http://orac.ece.utexas.edu/pub/svn/1.6.7/ Please be sure to test the bindings. I imagine I am not the only one that is getting back to the real world today. What is the state of this? Should we still run the tests and sign or will we be re-rolling? I did not follow the conversation on the bindings errors too closely over the holiday. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Apache, Subversion hooks, and locales
On Mon, Jan 4, 2010 at 8:43 AM, C. Michael Pilato cmpil...@collab.net wrote: But what about original problem with encodings? If I recall correctly, Apache is intentionally locale-ignorant. Like, not just I don't know about the system locale, but I'd like to ignore the system locale. On purpose. For reals. Would an appropriate workaround for this problem be to introduce a mod_dav_svn configuration directive which allows admins to dictate the locale of their hook environment? Could we just declare that the paths are passed as UTF-8 strings? Most of the hooks do not receive paths, right? So this is kind of specific to the lock hooks. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Apache, Subversion hooks, and locales
Mark Phippard wrote: On Mon, Jan 4, 2010 at 8:43 AM, C. Michael Pilato cmpil...@collab.net wrote: But what about original problem with encodings? If I recall correctly, Apache is intentionally locale-ignorant. Like, not just I don't know about the system locale, but I'd like to ignore the system locale. On purpose. For reals. Would an appropriate workaround for this problem be to introduce a mod_dav_svn configuration directive which allows admins to dictate the locale of their hook environment? Could we just declare that the paths are passed as UTF-8 strings? Most of the hooks do not receive paths, right? So this is kind of specific to the lock hooks. We have the ability technically to pass UTF-8 strings to the hooks. Add flags down the code stack towards svn_io_start_cmd() that say Don't convert the parameters, or somesuch. But is it the right thing to do? On the plus side, it relieves us of any concern with locale handling in these parts. But this puts the conversion burden on each and every hook script. And keep in mind that it's not just the input to the hooks at stake here -- we also need to consider the output from them (stdout and stderr messaging). Do we then also expect the hooks to generate UTF-8 output instead of output in the system's preferred locale (so we can package it up correctly for transmission back to the client)? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
1.6.7 Update
There have been several reports of problems in the 1.6.7 tarballs, so I'm feeling inclined to pull them and re-roll as 1.6.8 with the most recent fixes on the 1.6.x branch. I would not reroll until the ruby binding segfault has been fixed. Thoughts? -Hyrum
Re: Předmět:,Backends issues overview and SQL backend features
Jan Horák horak.ho...@gmail.com writes: Hi, while I'm preparing to SQL backend analyses/design I've wrote up some FSFS and BDB issues and then some features, that can be expected from SQL backend. I will appreciate any reaction to following points (sorry for the length, but I tried to short it as much as possible). First FSFS and BDB issues: -- * BDB is not portable The BDB libraries work on a large variety of platforms, the BDB database files are architecture independent and can be moved between machines with different architectures. It's only the BDB environment files that are machine specific, is that a significant problem? Now expected features of the SQL backend: -- * good read-able by human without need of using db_dump utilities Are SQL databases human readable? I always assumed that one used a front-end query tool, although I do admit that those tools are much more user friendly than BDB's db_dump. -- Philip
Re: Subversion in 2010
On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: To be a compelling replacement for git/Mercurial, perhaps? That seems tough. The major architectural differences between git/Mercurial/Bazaar and Subversion are: * No commitment to mixed-revision working copies. * Full history of at least one branch is generally stored on clients. * DVCS workflow support. For small projects and a certain class of developers, these can be huge advantages. For huge projects and a different class of developers, these can be hindrances. (See also http://svn.haxx.se/dev/archive-2008-04/1020.shtml)
Re: svn commit: r895677 - in /subversion/branches/1.6.x: ./ CHANGES STATUS subversion/libsvn_client/merge.c subversion/libsvn_subr/mergeinfo.c subversion/tests/libsvn_subr/mergeinfo-test.c
On Jan 4, 2010, at 11:18 AM, Bert Huijben wrote: -Original Message- From: hwri...@apache.org [mailto:hwri...@apache.org] Sent: maandag 4 januari 2010 17:17 To: comm...@subversion.apache.org Subject: svn commit: r895677 - in /subversion/branches/1.6.x: ./ CHANGES STATUS subversion/libsvn_client/merge.c subversion/libsvn_subr/mergeinfo.c subversion/tests/libsvn_subr/mergeinfo-test.c Author: hwright Date: Mon Jan 4 16:16:23 2010 New Revision: 895677 URL: http://svn.apache.org/viewvc?rev=895677view=rev Log: Reintegrate the 1.6.x-r39019 branch: * r879093 Fix bug where svn_[rangelist|mergeinfo]_[merge|intersect|remove|diff] APIs can modify their *non*-output arguments. Justification: No reports of this causing any problems that I know of, which is probably due to the fact that users of an API like svn_mergeinfo_merge typically only care about the output arguments. The new C tests added to mergeinfo-test.c clearly demonstrate the bug. Branch: Resolves a minor conflict in libsvn_client/merge.c where the code changed was refactored on trunk. ^/subversion/branches/1.6.x-r39019 The relevant commit on the branch is r879175. Votes: +1: pburba, julianfoad, rhuijben Modified: subversion/branches/1.6.x/ (props changed) subversion/branches/1.6.x/CHANGES (props changed) subversion/branches/1.6.x/STATUS subversion/branches/1.6.x/subversion/libsvn_client/merge.c subversion/branches/1.6.x/subversion/libsvn_subr/mergeinfo.c subversion/branches/1.6.x/subversion/tests/libsvn_subr/mergeinfo-test.c Propchange: subversion/branches/1.6.x/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Jan 4 16:16:23 2010 @@ -17,6 +17,8 @@ /subversion/branches/1.6.x-r38572:875006-875011 /subversion/branches/1.6.x-r38799:875225-875262 /subversion/branches/1.6.x-r38927:875347-875521 +/subversion/branches/1.6.x-r39019:879132-895676 +/subversion/branches/1.6.x-r39109:879131 What happens here I think you triggered an old bug here that should be resolved by a previous merge? Dunno. I was using the latest 1.6.x client to do this merge, so it shouldn't be a already-fixed bug. -Hyrum
Re: Subversion in 2010
I know it's been a trouble-some subject, and a lot of effort has been invested already, but - I would like to see ensuring reliable merges across branches remain as a priority, even if it is only a priority to address defects. Parallel development is one of the most important features of a source management system. Reliable merging across branches is a huge part of this for large projects that cannot work on trunk and hand manage porting changes from one release to another. We are still seeing reports that Subversion merges across branches are failing in areas where we expect them to succeed. I am encouraging our teams to move from ClearCase to Subversion, and the merge limitations of Subversion that can either lead to lost productivity in performing the merge, or downstream consequences in the case of a faulty merge that is not detected, is a major obstacle. I cannot in good faith say that Subversion merging is at the same maturity as ClearCase merging. In my experience, I find GIT merging between branches to be superior to Subversion merging between branches. Where Subversion too frequently ends up with the incorrect results, GIT only rarely results in incorrect results. I would like to see Subversion catch up in this crucial area. Again, I appreciate the unique difficulties that the Subversion architecture introduces, and I appreciate the efforts done so far - merge tracking in 1.5, tree conflict resolution in 1.6 - but this area still needs work. From Subversion 1.4, it has gone from extremely poor support for merging across branches, to 1.6 where I would call it nearly complete, still containing known defects. Another related area of limitation here is the reintegrate. This seems fundamentally broken to me. That the branch needs to be removed and re-created in order to reintegrate again indicates a flaw in the design. Under ClearCase and GIT, they both support reliable repeated merges in both directions. This may be another issue where the Subversion architecture introduces unique difficulties - but to any user of the system, we do not care what unique architectual limitations exist - we just want a reliable product that works in our standard work flows and that works just fine in other competing products. Why doesn't it work in Subversion? For many projects - switch to GIT or another system is a preferable option. It has other features that make it desirable over Subversion. However, there are projects that would work best under a centralized model such as Subversion. I think chasing the de-centralized solutions will leave Subversion in the past. Subversion's architecture limits it from providing many of the capabilities of the de-centralized solutions, and I tend to think that Subversion should not try to be everything to everyone (and fail), but work to its strengths. Subversion's main benefits in my opinion are: 1) Wide tool integration, 2) Ease of use, 3) Centralization. Perhaps it should become the work to maintain and enhance it's title in these areas? I'd like to help where I can. I haven't found an opening to start contributing yet. Another priority I have is performance. I find Subversion extremely slow for large projects. This is all relative - as I find ClearCase similarly extremely slow, but there are particular cases where it seems Subversion exhibits worst case behaviour for. For example, commits of 100,000 files is an area where Subversion seems to crawl. Importing a vendor branch is this sort of scenario, but it extends to having downstream consequences if Subversion replication (svnsync?) is used or if other tools consume the results (FishEye?). The merge problems are easier to define than performance problems, as merge problems can effect everybody and can be shown to work or fail with reproducible test cases, whereas performance problems are related to productivity expectations and harder to put $$$ value on that everybody would agree to. Cheers, mark On 01/04/2010 11:31 AM, C. Michael Pilato wrote: A hearty +1 to all of what you've indicated! Additionally, in 2010, I'd like to work with other devs that care to restore some sense direction to this product. At a minimum, that means identifying and killing the bugs and misfeatures that are impeding forward motion, and thinking farther ahead than just the next release in terms of feature planning. If asked to name specific TODO items, I'm not sure I'm ready to do that today (which itself is probably a symptom of the overall problem), but surely amongst the lot of us we can begin to shape the future of Subversion. We may never achieve a vision as concise as to be a compelling replacement for CVS. Or maybe we will. To be a compelling replacement for git/Mercurial, perhaps? -- Mark Mielkem...@mielke.cc
Re: Subversion in 2010
On Fri, Jan 1, 2010 at 1:22 PM, Hyrum K. Wright hyrum_wri...@mail.utexas.edu wrote: I hope the holidays have been good for everybody in the Subversion community. In between spending some quality time with family, and eating more than I ought, I've done a bit thinking about Subversion in 2010, what I'd like to see happen, and some goals that we can work toward as a community. Here's my list (in no particular order): * Release 1.7 with wc-ng and obliterate support * Build our developer community * Finish joining the ASF and dissolve SVN Corp * Talk to users more * Build out our web presence on s.a.o. I would like to see more time and effort put into defining and communicating our roadmap for the next several releases so that users can see that we still have a vision for the future, and if necessary, provide feedback to us on changing that vision. I think your bullet points are saying essentially the same thing. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Subversion in 2010
On Mon, Jan 04, 2010 at 01:01:14PM -0500, Mark Mielke wrote: Again, I appreciate the unique difficulties that the Subversion architecture introduces, and I appreciate the efforts done so far - merge tracking in 1.5, tree conflict resolution in 1.6 - but this area still needs work. I'd be really happy if we already had tree conflict resolution! Right now, Subversion can *detect* tree conflicts, but it is far from resolving any of them automatically. Stefan
Re: Subversion in 2010
On Mon, Jan 04, 2010 at 01:17:51PM -0500, Mark Phippard wrote: On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke m...@mark.mielke.cc wrote: Another related area of limitation here is the reintegrate. This seems fundamentally broken to me. That the branch needs to be removed and re-created in order to reintegrate again indicates a flaw in the design. The branch does not have to be deleted, that is just the simplest thing to recommend. You can use --record-only to record the reintegrate merge on the branch and then just continue. I've seen this answered and explained dozens of times so I will not go into any more detail. See here, for example: http://mail-archives.apache.org/mod_mbox/subversion-users/200912.mbox/%3c20091220185906.ga18...@noel.stsp.name%3e Stefan
Re: Apache, Subversion hooks, and locales
On Jan 4, 2010, at 5:48 AM, Mark Phippard wrote: Could we just declare that the paths are passed as UTF-8 strings? Any chance of declaring that the paths are not only UTF-8, but also *composed* UTF-8? -==- Jack Repenning Chief Technology Officer CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 twitter: http://twitter.com/jrep
Re: 1.6.7 Update
On Mon, Jan 4, 2010 at 12:11 PM, Hyrum K. Wright hyrum_wri...@mail.utexas.edu wrote: There have been several reports of problems in the 1.6.7 tarballs, so I'm feeling inclined to pull them and re-roll as 1.6.8 with the most recent fixes on the 1.6.x branch. I would not reroll until the ruby binding segfault has been fixed. Thoughts? AFAICT the ruby binding segfault is the only real problem with 1.6.7. The python mergeinfo test failure mentioned by Stefan was due to incorrect test expectations. Bhuvaneswaran's build problems sound like issues with his setup. Is there anything else? Regardless, assuming the Ruby segfault is a regression, I'm all for skipping 1.6.7 and rolling 1.6.8 once it is fixed...so, is anybody looking at that? Paul
Re: Subversion in 2010
On Mon, Jan 04, 2010 at 01:45:07PM -0500, Mark Mielke wrote: On 01/04/2010 01:25 PM, Stefan Sperling wrote: On Mon, Jan 04, 2010 at 01:01:14PM -0500, Mark Mielke wrote: Again, I appreciate the unique difficulties that the Subversion architecture introduces, and I appreciate the efforts done so far - merge tracking in 1.5, tree conflict resolution in 1.6 - but this area still needs work. I'd be really happy if we already had tree conflict resolution! Right now, Subversion can *detect* tree conflicts, but it is far from resolving any of them automatically. If it doesn't resolve them (any? all?) yet, then this would explain one of the results I saw and couldn't explain. It knew the files had moved, it said it completed the merge - but the merge was missing. I became too busy to chase it down! :-( Out of curiosity, where did you get the idea from that Subversion could resolve tree conflicts for you? Is there documentation which is not clear enough and needs to be fixed? Thanks, Stefan
Re: svnsync 207 Multi-Status failure with http access method and property svn:
Self-bump and post to dev list also. Posting 2 days before Christmas seems to be a bad way to get a response ... ; On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg k...@kylo.net wrote: Preparatory to setting up a proxy server, I'm trying to svnsync a repository from 1.6.6 server to another 1.6.6 server (both x86_64 linux, one Fedora 7, one Fedora 12). Some user somehow managed to create a property svn: on a file and the svnsync fails like so: Transmitting file data .svnsync: At least one property change failed; repository is unchanged svnsync: PROPPATCH of '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml': 207 Multi-Status (http://hood) I'm able to reproduce (what I assume is) the same problem without svnsync: 1) create a repo, with both svn and http access methods 2) via svn access method create a file, set an svn: property, and commit it, e.g. svn co svn://snow/test test cd test/ echo foo foo.txt svn add foo.txt svn ps svn: asdf foo.txt svn ci -m testing 3) now try to access it via http: svn pl http://snow/test/foo.txt svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow) So two questions here: 1) Is this a known issue? (I didn't see it in the bug db.) If not, can I get a second nomination that this is a bug? (If someone can point me in the right direction, and if this is likely to be a somewhat surgical fix, I'd be happy to attempt a patch.) 2) Any recommendations on how to proceed? For the initial sync of repos I can probably force the issue by svnsync'ing via the svn access method, but I don't think this will work once I set up write-through proxying. Thanks! Kylo
Re: Roadmap for 1.7 end game?
On Thu, Dec 17, 2009 at 06:18:28PM +0100, Stefan Sperling wrote: On Thu, Dec 17, 2009 at 06:12:43PM +0100, Stefan Sperling wrote: I still have some work to do for svn patch. The current hunk-application code ends up ignoring valid hunks in certain situations. I already know how I want to proceed, just need a bit of time to do it. I probably won't have time until mid of January, though. There is on issue filed for this task. I mean to say there is _NO_ issue filed for this task, The above mentioned non-filed issue has been fixed today. Most of what's still left to do is filed in the issue tracker: #3434 svn patch API should have a patch target filter #3460 svn patch is not fuzzy when applying unidiffs #3473 svn patch doesn't add files correctly #3493 svn patch skips missing directories #3556 svn patch ignores svn:eol-style #3557 svn patch shouldn't allow rejects by default There are also two TODO comments in patch.c: /* TODO: Get keywords from patch target. How? /* ### TODO mark file as conflicted. */ And this looks related, it should at least be looked into: #3362 svn diff creates patch which does not reapply without fuzz Stefan
Re: Subversion in 2010
On Mon, Jan 4, 2010 at 5:27 PM, Karl Fogel kfo...@red-bean.com wrote: So maybe a way to approach this is to ask: For those for whom Subversion is currently the best solution, what *else* do they need it to do? From users I have heard from the two main themes would be: 1) Performance 2) Handling of move/renames Of course there are always other issues like server-based configuration etc. but these seem to be the consistently mentioned themes. And I call them themes because both of these manifest in a lot of different ways and need improvements in many areas across the product. It is probably worth noting that Git, and probably all of the DVCS options, are particularly strong in these two areas. I suspect if we could make significant improvements in these areas we would remove the desire of a lot of people to migrate away from SVN. I still believe the number of users that want or need the distributed workflow model is a small minority, especially in the corporate world. I also think as a community we need to do a better job evangelizing the strengths of SVN against the DVCS tools, in addition to addressing the areas where we are weaker and can make improvements. BTW, I do not think Mike was suggesting we try to be a compelling replacement for DVCS. I assumed that was a semi-joke or was at least meant to make the point that we as a community need to decide what we want to be. Perhaps more importantly what do we want to be that we are also committed to implementing. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: svnsync 207 Multi-Status failure with http access method and property svn:
Is svnserve really allowing you to create a random svn: junk property? I was pretty sure that servers validated svn: properties -- only a scant few exist, and users aren't supposed to be able to invent them. My guess is that apache is throwing an error (207 mult-status probably contains a 5XX code inside it somewhere) when it fails validate the outgoing svn:asdf property, and then the svn client chokes on the error. On Mon, Jan 4, 2010 at 10:36 AM, Kylo Ginsberg k...@kylo.net wrote: Self-bump and post to dev list also. Posting 2 days before Christmas seems to be a bad way to get a response ... ; On Wed, Dec 23, 2009 at 1:13 PM, Kylo Ginsberg k...@kylo.net wrote: Preparatory to setting up a proxy server, I'm trying to svnsync a repository from 1.6.6 server to another 1.6.6 server (both x86_64 linux, one Fedora 7, one Fedora 12). Some user somehow managed to create a property svn: on a file and the svnsync fails like so: Transmitting file data .svnsync: At least one property change failed; repository is unchanged svnsync: PROPPATCH of '/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml': 207 Multi-Status (http://hood) I'm able to reproduce (what I assume is) the same problem without svnsync: 1) create a repo, with both svn and http access methods 2) via svn access method create a file, set an svn: property, and commit it, e.g. svn co svn://snow/test test cd test/ echo foo foo.txt svn add foo.txt svn ps svn: asdf foo.txt svn ci -m testing 3) now try to access it via http: svn pl http://snow/test/foo.txt svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow) So two questions here: 1) Is this a known issue? (I didn't see it in the bug db.) If not, can I get a second nomination that this is a bug? (If someone can point me in the right direction, and if this is likely to be a somewhat surgical fix, I'd be happy to attempt a patch.) 2) Any recommendations on how to proceed? For the initial sync of repos I can probably force the issue by svnsync'ing via the svn access method, but I don't think this will work once I set up write-through proxying. Thanks! Kylo
RE: Subversion in 2010
On Mon, January 04, 2010 at 5:59 PM, Mark Phippard mailto:markp...@gmail.com wrote: From users I have heard from the two main themes would be: 1) Performance 2) Handling of move/renames Of course there are always other issues like server-based configuration etc. but these seem to be the consistently mentioned themes. And I call them themes because both of these manifest in a lot of different ways and need improvements in many areas across the product. I think these are themes because they currently are having the most impact on enterprises, but they are not nearly the extent of what enterprises want from Subversion. Centralized configuration control is an example as you've mentioned, but there are others. I'm about to start an effort that I hope will help galvanize input from enterprises to make their desires more clear as well as provide a means for community ideas to be vetted by enterprises. I'd like to see this also work as a means of gathering financial support to get some of the things they see as critical implemented. I've talked to a few of you at the Subversion Conference about this and have had great responses from the enterprises that I've interacted with since then. CollabNet has interacted with a large number of enterprises that we'll engage in this effort. Hopefully this can help with the effort to define a roadmap for the community as I'm sure it will help with CollabNet's own roadmap for contributions. Stay tuned! Bob Jenkins
