Thats strange...in fact you are blaming the vcs for something it has no
control over.
Maybe you could whip up a script to synchronize the svn checked out copy
of your project with the generated stuff from Xilinx? Or maybe Xilinx
can make their IDE vcs aware :)
If you are on unix you might create a copy and move script (or alias)
that just calls svn equivalents of these commands when the scrips are run.
Hugo
Øyvind Harboe wrote:
> 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.
>
Received on Wed Aug 10 03:43:20 2005