Current state of duchain/parser

[Jakob Petsovits]

On Monday, 21. May 2007, Kris Wong wrote:
> > Generalize it, so that it can be used for languages other than C++.
> > Make the C++ one just a specialization of the general duchain.
>
> I did quite a bit of work in this area this past Sunday.  Here's an
> overview of the changes:
>
> 1. Moved the majority of duchain into lib/language/duchain
> 2. Added one additional interface, ICodeHighlighting, in
> lib/language/interfaces
> 3. Moved the remaining C++ specific classes (builders, c++ type classes,
> and type repository) from languages/cpp/duchain to
> languages/cpp/duchainbuilder

Teh awesome!

> None of this is committed yet, mainly because this is going to be quite
> a task in svn.  Matt R had suggested using the svn move command to move
> the files around, but it seems this does not support moving between
> repositories.  Is there a way to go about this w/o having to
> remove/re-add the files (thus losing history information)?

You are not moving those files between different repositories. KDevelop is 
contained in one universal repository, so if you don't move your files to 
SourceForge & Co., it will definitely work.

SVN, however, is slightly annoying when moving files that have already been 
modified, it doesn't want to move them without specifying --force, if I 
remember correctly. So if that is the problem, you could proceed as follows:

1.
Copy your complete kdevelop/ checkout to another place,
e.g. kdevelop-duchain/ lying in the same directory where kdevelop/ lies.

2.
Do an "svn revert ." in your original kdevelop/ directory, assuming that you 
haven't yet moved any files. If you have, get a new checkout of kdevelop/.

3.
Do an "svn mv" in your original kdevelop/ directory for each file or directory 
that needs to be moved to lib/language/duchain.

4.
Copy over the modified files from the kdevelop-duchain/ directory, replacing 
the files that you have just moved into the new locations. If you don't 
remember which files have been modified, you can always do an "svn status" 
(in the kdevelop-duchain/ dir) to make sure you don't forget anything.

5.
Compile, test, commit.

That method should work in any case, I think. It's what I do to accomplish 
clean moves, when there are more complex changes to be committed.

> I was planning to do this this evening (around 10:00 EST).  Unfortunately,
> no matter how I go about this, it's not exactly going to be atomic.
> I would be cautious in doing an svn up for a short while after this time.

I think that shouldn't be much of a problem, if breakage doesn't last very 
long (say, KDevelop not being compilable for more than one day would be bad, 
but if it's just for an hour or so, no one will be mad at you).