Issues with AppWizard and VCS

Sascha Cunz sascha at sacu.de
Sun May 2 13:04:27 UTC 2004


Hi all,
recently a discussion came up about the fact that all vcs plugins are global 
ones, which is due to the fact that they are needed in appwizard to create a 
new repository.
Now, that we have started a step by step redesigning of AppWizard, we came 
across this issue, again. We wanted to find a way to make the vcs plugins not
global.

Our first approach was, to present the user a list of posibly available vcs 
plugins in AppWizard and load one of them as the user selects it.

In a talk last evening, we (that is Jens and me) discussed this once more:
 - Adding this stuff to appwizard means adding a lot of overhead which will
   posibly be used very rare.
 - It still gives us not the ability to create a repository out of an existing
   project.

As of my memory, creating a repository out of an existing project is painful. 
In case of CVS you have two choices:

a) using "cvs import":
    - create a Project with KDevelop in foo/bar
    - create meaningful .cvsigonre files in foo/bar
    - use cvs import on foo/bar
    - use cvs checkout on foo/baz
    - nuke foo/bar
    - continue working with foo/baz
   The checkout is neccessary, because cvs won't create the 'CVS'-subdirs in
   the foo/bar directory structure.

b) using cvs "add":
    - create a Project with KDevelop in foo/bar
    - create meaningful .cvsigonre files in foo/bar
    - ssh to cvs server and "mkdir $CVSROOT/bar"; back on development box:
      "cvs co bar" to some/place and "mv some/place/CVS foo/bar"
      (Or any other way to get a "good" CVS sub dir to the root of the project
      dir)
    - now cvs add each and every file (using kdevelop, cervisia, comand line
      ect) and commit it.

I personally think, that both ways are very bloody to go - still i haven't 
seen a better approach. However, the most annoying thing is that i have to 
setup meaningful .cvsignore - files on my own.
To solve this by now, i propose to use signal similar to the way we're 
creating context menus now. smth like:

  public signal:
    void collectFilesToIgnoreList( QStringList& fileList );

Every part that creates / maintains temporary files (or even patterns) inside 
the project root could connect to that signal and insert it's temporary files 
or patterns into the list. The vcs could then break it up into to directories 
again and create appropiate ignore files.

So, our adjusted plans to go with appwizard look like:
  - create a repository-creation wizard
  - move vcs integration out of the appwizard
  - add a checkbox to appwizard, which will (if checked) trigger the
    repository creation wizard after the project has been fully created.

The repository creation wizard still would work like: query KTrader for 
vcs-plugins; let the user select one of them; occassional load one of them 
and present a "config" page.

We could then store the information used to access the vcs inside the project 
dom; which allows us to load a vcs plugin to be loaded with the project - and 
not globally.

Well, still there remains the "project import" tool. It allows the user to 
create a project out of a vcs. It probably needs to be split up, too. It 
could be a "fetch source wizard" (Other Import functionality is about to be 
merged to appwizard, anyway.)

Mario, as i'm only working with CVS, can you tell me, if there is another way 
to clearly determine which vcs a given directory uses, if any?

What i want to do with that information is: The user still is able to check 
out something to his local disc and any time later decide to work on that 
with kdevelop. Most probably he then has to import the files. If our vcs 
plugins aren't globally anymore, we have to save which one we use inside the 
project dom. This results in the fact that on importing, we have either to 
ask the user whether he wants to use vcs or not - and if yes, which one.

Cheers
  Sascha




More information about the KDevelop-devel mailing list