Hi Stefan,
Sure, this is something that I'm willing to try.
It is not a coincidence that I stumbled onto this '"corner case", I think.
For this task I'm currently working on I'm probably stretching Subversion
beyond it's intended use. To give you an idea: I'm using a script to prepare
a massive commit that affects several thousands files. This commit is
intended to cleanup a repository of a large project (+- 90 people) that have
been committing changes for a few years, with little
training/guidance/direction/control.
It seemed like a good idea at the time to do the cleanup in one fine sweep
(Subversion commit) in this running project. So what I now have is a Ruby
script that I can run against a working copy that enforces several rules:
naming, structure conventions, removes obsolete files, old files, backup
files, duplicate files etc.
There are similarities between what I'm doing with Ruby and what you are
doing with Python I think. Because the cleanup operation is so massive I
decided to automate it using Ruby. You could say I have created a simple
Ruby model layer on top of the Subversion command line client to help define
and apply the cleanup rules. Just a simple example to give you an idea: I
can find a folder and af file in my working copy by basename
f, d = Document.find_by_basenames('some_folder', 'some_file')
and then move the document to that folder
d.move(f)
Working on this task I have found three issues with Subversion. The path not
found is a show stopper for me, I still need to find a workaround for that.
If you can quickly give some pointers for adding such Python tests I'm
willing to give it a go. For example: do I need to a development environment
to build Subversion myself from the trunk? What documentation is relevant
for this task?
Best Regards,
Onno
On Fri, Jul 2, 2010 at 1:45 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Jul 02, 2010 at 11:42:58AM +0100, Julian Foad wrote:
> > Any objection to this step? The only down side I can think of is the
> > slight inconvenience for us developers of having to quote the path on
> > the command line when debugging the tests, and that's not something that
> > should put us off.
>
> -1
>
> I tend to find spaces in filenames I work with on the command line quite
> annoying. So I'd prefer explicit unit tests which check for whitespace
> within local paths and within URLs, much like what you listed below.
>
> Onno, do you have time and some rudimentary python skills (or time
> to pick those up)? If so, it would be great if you could contribute
> a couple of such tests (you could start slowly with just one test,
> get it reviewed and committed, and then do more if you want to).
> That would help us a lot in catching such bugs in the future.
>
> Thanks,
> Stefan
>
> > Then we can work on extending the principle in one or more different
> > ways, which, I'm sure, will detect a bunch of bugs:
> >
> > * space in some of the within-WC paths;
> >
> > * other ASCII pathnames that require URI-escaping, or in any other way
> > have the potential to be mis-handled by Subversion;
> >
> > * non-ASCII characters (but the ability to do this would depend on
> > what locales the test platform supports, and so would require
> > configuration magic to enable it);
> >
> > * similar things for repository-side paths.
> >
> > - Julian
> >
>
Received on 2010-07-05 10:33:54 CEST