Andreas Pakulat wrote:
> On 30.04.07 09:34:40, Jakob Petsovits wrote:
>> * I think isValidDirectory() should be named
isWorkingCopy(), because on
>> reading this name you instantly know what is asked
for.
>> ("what does valid mean here?")
>
> Well, WorkingCopy seemed to be too svn-ish...
(Since Jakob asked for suggestions...) I would actually vote
for
isWorkingCopy also. Maybe it's svn-ish but we're also using
svn
definitions for some things that are used differently
elsewhere (e.g. in
perforce, "merge" is resolve(), and
"integrate" is merge()). In some
cases we just have to pick a standard, and I agree that
isWorkingCopy is
more obvious than isValid. If you want a generic
alternative, IMO use
isVcsControlled. Hmm, you could also overload that to work
on files
also, which might be useful, although it would overlap with
status().
>> * edit() is also not quite what the method is
doing, how about setEditable()?
>
> IMHO setEditable is not really proper, for me it always
means setting a
> flag, which is not the case here. This may mean to
fetch a file from the
> repository to make it editable.
>
>> * repositoryRevision() vs. localRevision() - what
is the difference here?
>
> Simple: repositoryRevision() will give you the revision
of that file on
> the repository, local will give you the local revision
(i.e. svn info
> foobar, for example). This is the same after update()
or commit() but
> might be different in other times.
Should repositoryVersion() return the very latest global
version of the
repo, or the latest change that affected the file in
question? I want to
say the latter?
Anyway, I guess I am also confused; why is the difference
not simply
whether you gave a repo path vs. a url (i.e. one function)?
(But I guess
this needs the url->repo path function?)
I also realized something unfortunate, but probably
unavoidable... it is
really hard to get the repo version of a directory with
perforce. All I
can figure out to do is get the file version of every file
in the
specified path and compare that to the log() of that path,
working
backwards until you find the revision at which point going
further back
would mean reverting to an earlier version of some file in
that path.
>> Question: what dstRevision will the method receive
if the LocationDst is a
>> locally modified file inside the working copy?
That's important to document,
>> as it's the primary use case.
>
> I don't think dstRevision should be used in that case,
dstRevision is
> meant to be used when specifying a repository location.
Maybe we
> shouldn't do this in 1 method but split those that can
take either repo
> location or local one...
...or use the version "WORKING"? This would allow
specifying a file by
local path but diffing a repo version. Alternatively, just
ignore the
parameter in this case (do we really need multiple
versions?).
--
Matthew
If you believe you received this e-mail in error, you are
probably sadly
mistaken, but if not, aren't you lucky?
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
