[VCS] Merging IAtomic* into IBasic*

[Matthew Woehlke]

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?)? More 
importantly, are we stating that only one repository may be used per 
project? 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).

>> 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 I guess this would be a 
pointer to the project also, but it has to be present. 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?)

>> 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? ;-) Anyway, 
yes, as long as the plugin can get access to the correct project, this 
is fine.

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

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

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