On 12/20/06, Ph. Marek <philipp.marek@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.
Received on Thu Dec 21 07:54:46 2006