[VCS] Merging IAtomic* into IBasic*

[Andreas Pakulat]

On 11.05.07 10:02:34, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 10.05.07 18:22:00, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >>> On 10.05.07 15:29:54, Matthew Woehlke wrote:
> >>>> Andreas Pakulat wrote:
> >> Step back a second. Perforce is useless without P4USER, P4CLIENT and 
> >> P4PORT, which are environment variables that do not appear 'as part of 
> >> the file system' and are not defined in a repository path. So, either 
> >> the instance of the VCS plugin needs to know this information
> > 
> > It can't because one instance of perforce plugin is going to be used on
> > different projects with different repositories.
> > 
> >> , or repositoryRoot should take a /local/ path that would contain this
> >> information (in the latter case, using the perforce plugin would mean
> >> it creates .p4 files containing the server information).
> > 
> > Well, actually repositoryRoot can take a ProjectBaseItem, because it
> > won't work with a plain KUrl that is not part of some project (because
> > in that case you can't find the project and get the information).
> 
> Remind me, was there at some point an objective to support multiple 
> VCS's per project (I guess that wouldn't work very well though?)?

I don't see a real reason for that. If you have a large project that
consists of several sub"things" that are stored in different VCS then
you can have these things as several projects in KDevelop that depend on
each other.

> More importantly, are we stating that only one repository may be used
> per project?

Yes.

> Anyway if we say 'one project, one repository', then a pointer 
> to the project would suffice for things that only need to know the 
> address of the VCS server (and e.g. user name, etc).

No, a KUrl that is part of a project is sufficient, because you can find
the project from that.

> >> Additionally, if the plugin is to not have state knowledge, then /every/ 
> >> method must take a local path or repository path.
> > 
> > Why? 
> 
> Well, as discussed above, everything that might need to talk to the VCS 
> server needs to know where the server is.

So there are functions in our interfaces that don't take a repo or local
path.

> Honestly I think I would rather see one plugin instance per project,
> which knows about the repository. Is the overhead of this really so
> bad? (Or is it just not possible with the platform?)

Its not supported by our platform and its also not going to be. We state
clearly in our platform documentation that any plugin is expected to
either handle 0 or N projects. There's no exception to that for VCS
plugins.

If a manager expects to handle really large projects it should have a
cache of urls that belong to the project and thus asking for the project
of a given url is rather fast. When you've got the project you can read
the settings from its KConfig file.

> >> Incidentally, what happens if the plugin needs to ask you for a 
> >> password? Use KWallet I guess?
> > 
> > See above, project config file can store this.
> 
> And... maybe we can have an option to not save it on disk? ;-)

Thats subject to the plugin implementation, svn for instane stores the
password in clear-text by default (unless you specify a flag in your
subversion config file). Of course storing them in the .project file
might not be a good idea if the file is readable to others.

> >> So I guess in order to use a VCS Browser GUI (think 'websvn') you would 
> >> have to tell it the server+root first?
> > 
> > Hmm, this should be something that is stored in the vcs plugin config
> > (i.e. the repository roots).
> 
> Huh? This information is different per each repository, for KDevelop it 
> can be stored as part of the project, for a GUI the usual way is to ask 
> on startup (or of course use last). I guess a GUI would implement a 
> 'dummy' project if using the KDevelop interfaces. :-)

What I mean is if I want to browse a VCS without having a project for
that? Whats the problem of storing a list of repositories and their
access information? I don't think I should get 20 dummy projects just
because I browse 20 svn repos. 

And a general-vcs-gui on top of the platform would only have project for
things that have been checked out, not for browsing a repository.

> >> Maybe we need to rethink repo paths as containing three data items;
> >> user, server, path, and additional information as required by the VCS.
> >> You could still store this as a string, but that means the perforce
> >> backend would have to parse these critters all the time (not a big
> >> deal I guess, 'svn' is doing it anyway). So a perforce repo path now
> >> looks like
> >> 'p4://mwoehlke_kde_trunk.mwoehlke at perforce.kde.org:1666/path/to/foo.c'
> >> (if it has to look /almost/ like a URL, I prefer making it look all
> >> the way like a URL :-)).
> > 
> > Better make it a proper class with some getter/setters. Makes repo paths
> > re-usable by adjusting the path. Then wrapping it in QVariant and be
> > done.
> 
> Right (actually I was kind-of assuming KUrl provided that sort of thing, 
> but VcsUrl would be fine also).

I'd rather not call it VcsUrl but KDevelop::RepositoryAccessor or
something like that. Its not really a url for things like CVS or others.

Andreas

-- 
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.