On Tue, 2005-08-09 at 09:00 -0400, Mark Phippard wrote:
> You are missing a key point. When you use Subversion, you need to allow
> Subversion to "own" your working copy. Subversion is not file-based like
> CVS, it is tree-based. So it needs full control of the tree. You cannot
> use the operating system delete, move, copy, rename etc.. commands within
> the WC. You have to use the Subversion commands. There is no way to use
> the OS command first, and then "tell" Subversion about it later.
>
> In Eclipse, with Subclipse, we capture all of the Eclipse commands like
> copy, delete, move and route then through the Subversion commands for you.
>
> There is no way around this. Subclipse has to live by the rules that are
> established by Subversion. Your only option is to either modify or not
> use these scripts.
I see. Shame really.
There are some projects that are forever out of subversion's reach then.
E.g. Xilinx FPGA IDE projects we keep under Eclipse CVS today. The
Xilinx IDE deletes, moves, copies files blissfully ignorant of CVS and
then subsequently and independently we can fire up Eclipse and
synchronize against + commit against CVS.
When these sort of projects are involved, I don't forsee one CVS and one
subversion server being maintained, hence the switch to subversion will
never happen in these cases.
Thanks for the clarification.
--
Øyvind Harboe
http://www.zylin.com
Received on Wed Aug 10 03:05:11 2005