On 12/21/06, Eric Hanchrow <offby1@blarg.net> wrote:
>
> >>>>> "Dave" == Dave Thomas mailing lists <davelist@peoplemerge.com>
> writes:
>
> That's your problem right there. If you're using subversion, you
> mustn't do stuff "behind its back" -- i.e., don't just delete files;
> instead, do 'svn rm' on them. And when you create new files that you
> want versioned, run "svn add" on them.
See, that's the thing. The project is pretty much an abstraction layer on
top of eclipse with subclipse subversion bindings. Sorry for not explaining
this objective properly.
I need to test that the abstraction layer on top of subversion behaves
properly both before and after a commit. For example, tortise displays a
gray checkmark if a file has been committed, a red one if changes need to be
committed, nothing if unversioned and so on.
Do you think it's at all possible to save the changes made to a working copy
so they can be incorporated in a unit test?
Consider the test in the source tree at subversion/tests/libsvn_wc.
Doesn't this create some test data in a working copy then run tests against
it (adjusting the test data as it goes)? I'd like to do the reverse, since
I need to support application code as well. Create the working copy by
hand, somehow save state, then run automated tests against that.
Achieving this type of automation is farly straightforward on the
repository, but I guess there's really no easy way to do this on the working
copy.
Received on Thu Dec 21 21:58:50 2006