You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dave_Thomas mailing lists <da...@peoplemerge.com> on 2006/12/21 06:19:35 UTC
Getting the changes to the WC
Hi, I'm having trouble with the following use case, your insight is
appreciated.
A user's made a series of changes to his working copy, which include
creating some files (they're unversioned), and deleting others (they're
missing).
Another user of the same repo needs to make the same changes.
The natural thing would be to copy the working copy from one machine to
another. But shouldn't it be possible to avoid the bulk of that transfer?
It looks like the thing to do is to write a script that collects `svn info`
and walks the list, copying whole files or creating diffs as it goes. `svn
diff` looks like it might almost do this but reading it's output seems
difficult, and doesn't tackle unversioned files.
Looking at all the different status codes that svn status can return, it
looks like a bit of an undertaking.
Maybe someone's already made this tool?
Thanks in advance.
Dave
Re: Getting the changes to the WC
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 21 December 2006 21:58, Dave_Thomas mailing lists wrote:
> 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.
How about this idea: You take *another* versioning tool (svk might do the
trick) and use that for versioning your wc *including* the .svn-directories?
Then you could dump your svk-repository, and load it again as needed.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting the changes to the WC
Posted by Dave_Thomas mailing lists <da...@peoplemerge.com>.
On 12/21/06, Eric Hanchrow <of...@blarg.net> wrote:
>
> >>>>> "Dave" == Dave Thomas mailing lists <da...@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.
Re: Getting the changes to the WC
Posted by Eric Hanchrow <of...@blarg.net>.
>>>>> "Dave" == Dave Thomas mailing lists <da...@peoplemerge.com> writes:
Dave> A user's made a series of changes to his working copy, which
Dave> include creating some files (they're unversioned), and
Dave> deleting others (they're missing).
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.
Dave> Another user of the same repo needs to make the same
Dave> changes.
If you do what I suggest above, and then commit the changes, that
other user merely needs to run "svn up".
See http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html
--
It is possible that with more experience and maturity Scorsese
will direct more polished, finished films ...
-- Roger Ebert, 1969
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting the changes to the WC
Posted by Dave_Thomas mailing lists <da...@peoplemerge.com>.
On 12/20/06, Ph. Marek <ph...@bmlv.gv.at> wrote:
>
> [Trimming dev@]
>
> On Thursday 21 December 2006 07:19, Dave_Thomas mailing lists wrote:
> > A user's made a series of changes to his working copy, which include
> > creating some files (they're unversioned), and deleting others (they're
> > missing).
> >
> > Another user of the same repo needs to make the same changes.
> >
> > The natural thing would be to copy the working copy from one machine to
> > another. But shouldn't it be possible to avoid the bulk of that
> transfer?
> ...
> > Maybe someone's already made this tool?
> Yes, that's called "svn commit".
> Just check in to the repository, and the other user can update - it's as
> easy
> as that!
Alas, if only it were so. This is a kind of test harness, so I really do
need to preserve the state of all uncommitted changes, including unversioned
ones. For example, my application expects a file to be locked as it was
before. Since the other user won't inherit any lock on update, the
application will sadly exhibit different behavior...
If these are changes that you don't want on your main development line
> (unstable, experimental, only proof-of-concept), use a branch.
> You can switch the working copy without loosing the changes, so there
> should
> be no problem.
This is a terrific idea. Branching will solve a related problem, providing
an alternative to what I thought I'd need to resort to incremental dumps.
Re: Getting the changes to the WC
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
[Trimming dev@]
On Thursday 21 December 2006 07:19, Dave_Thomas mailing lists wrote:
> A user's made a series of changes to his working copy, which include
> creating some files (they're unversioned), and deleting others (they're
> missing).
>
> Another user of the same repo needs to make the same changes.
>
> The natural thing would be to copy the working copy from one machine to
> another. But shouldn't it be possible to avoid the bulk of that transfer?
...
> Maybe someone's already made this tool?
Yes, that's called "svn commit".
Just check in to the repository, and the other user can update - it's as easy
as that!
If these are changes that you don't want on your main development line
(unstable, experimental, only proof-of-concept), use a branch.
You can switch the working copy without loosing the changes, so there should
be no problem.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org