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