[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