[VCS] Merging IAtomic* into IBasic*

[Andreas Pakulat]

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:
> > About FileNumber: Those are actually meaningless without an associated
> > path - IMHO - so maybe the revision should carry this information (the
> > repo path) internally. Not sure if this should be made accessible, but
> > it might make sense..
> 
> Ok... if I pay attention and read that correctly, then yes, that makes 
> sense. Maybe we should note that this should be done, but it is really 
> an implementation detail.

Yeap.

> > Also the above doesn't work that way, there's no Repository class
> > anywhere so repositoryRoot() would at least need a repoPath to start
> > with.
> 
> 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).

> Additionally, if the plugin is to not have state knowledge, then /every/ 
> method must take a local path or repository path.

Why? 

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

> >> Also it's pretty important for a remote repository browser to know :-)
> >> (although I suppose it could require you to specify this).
> > 
> > Uhm, the vcs plugins don't have any state so they can't know the
> > repositoryRoot() without supplying them some information for what
> > file/repopath you want to know the root.
> 
> See above. This is a problem that needs to be resolved; if the plugin 
> has no state information then you will have to do special things for the 
> perforce plugin to be usable. Did I mention perforce in 3.4 is 
> *completely, 100% broken/unusable* for exactly this reason?

Hehe, see the buildtools (especially qmake manager and make/qmake
builder) for some ideas how this will work. Basically you just have to
ask the project.

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

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

Andreas

-- 
Do something unusual today.  Pay a bill.