[VCS] Merging IAtomic* into IBasic*

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 11.05.07 10:02:34, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 10.05.07 18:22:00, Matthew Woehlke wrote:
> [snip]
>> More importantly, are we stating that only one repository may be used
>> per project?
> 
> Yes.

Ok, that makes things easier.

>> 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.

Right, I'm considering a KUrl "heavier" (I guess because it imparts more 
detailed information than the project), but as you say, either suffices.

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

Right now change() only takes a VcsRevision. That might be the only one, 
I haven't done an audit yet.

>> 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.

Ok, all I needed to know. :-)

>>>> 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, [snip]

...but then something that is not the project config is storing the 
password? I guess you mean that it is up to the plugin implementation if 
it wants to use the project config or has its own method?

>>>> 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. 

The front-end would handle this so it would be totally invisible to the 
user, but...

> 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.

...now that you mention it, you're right, as long as you never deal with 
a local path the VCS plugins shouldn't be looking for a project anyway. 
So forget what I said. :-)

But I don't see why the plugin is remembering roots, wouldn't the 
browser front-end do that?

> 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.

That's fine, it's just a name. :-)

-- 
Matthew
find / -user your -name base -print | xargs chown us:us