On 7/9/05, John <jsparrow@ecclescollege.ac.uk> wrote:
> Quest <quest <at> lysator.liu.se> writes:
>
> > > In some ways I'd like my working copy to belong to
> > > two seperate repo's: a personal, local one for regular savepoints, and a
> > > central one for sharing.
> >
> > This sounds more like arch to me.
>
> I don't suppose it would be wise to keep two copies of .svn in the working
> directory would it, and do:
>
> move .svn .localsvn
> move .centralsvn .svn
> svn commit
> move .svn .centralsvn
> move .localsvn .svn
>
> (assuming .cenralsvn and .localsvn are in the ignore list).
>
> That's so crazy it might work.... ;)
>
I've done this with CVS before, but never tried with svn since it
handles vendor branches well. I had a make target that would switch
which repository's files were in the CVS directory.
Then I version controlled the external projects CVS files, with svn
that would be more problematic since it stores text-base and such.
This would have the side effect of making your working copy take up 3
times the space of the files contained.
If the goal is simply to create save points to avoid corruption you
might try writing a script that saves an svn-diff of your working copy
to a safe location, and then if something corrupts your working copy,
you can svn revert (or recheck out the directory) and apply the diff
file. If you want these versioned you can create a separate repository
to hold these, that would avoid creating extraneous commits in the
main repository, real check points would be checked into branches as
normal, it would be only these anti-corruption diffs that would never
go into the repository.
Or you could look at svk - it is a subversion based distributed system.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 9 22:23:32 2005