[VCS] Merging IAtomic* into IBasic*

Matthew Woehlke mw_triad at users.sourceforge.net
Fri May 11 17:54:14 UTC 2007


Andreas Pakulat wrote:
> On 11.05.07 11:00:41, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>> Right, I'm considering a KUrl "heavier" (I guess because it imparts more 
>> detailed information than the project), but as you say, either suffices.
> 
> Huh? KUrl's are shared and transferred as references, so its not heavy.
> And we need the KUrl anyway, so adding a Project* pointer is just
> additional parameter for no reason.

I didn't mean "heavier" in that respect... anyway don't worry about it, 
KUrl is fine, and we certainly don't need to pass around /both/. :-)

>>> 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.
> 
> Ok, yeah. I think the revision should take the repo-information
> (internally like the repo path for filenumbers)

Hmm... at first that makes a lot of sense, but the problem is I can't 
think of a way to do change(VcsRevision::Head) this way. Is it better to 
require constructing a VcsRevision to require a repo path, or should we 
just say that change() needs a repo path?

>> But I don't see why the plugin is remembering roots, wouldn't the 
>> browser front-end do that?
> 
> Well, I didn't think about that too much. I guess you're right. Just
> wanted to state that plain-browsing-repo-info shouldn't be stored in a
> project.

Right. That would only be the case if it was absolutely required, and 
/even/ if it was, the front end would hide this from the user.

>>> 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. :-)
> 
> Good, I recall that not everybody always has this opinion about names...

Oh, I don't /always/ not care :-) but in many cases I'm just tossing out 
the first name I can think of (which is why I often include 'suggestions 
for a better name welcome ;-)). This was very much one such case.

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





More information about the KDevelop-devel mailing list