VcsRevision usage question.

I'm not discussing the interface. I'm asking the usages.

When revision is RevisionType::GlobalNumber, then does the
QString revisionValue() returns the number using
QString::fromInt()??

When revision is RevisionType:ate,
then what is the format
of QString revisionValue() ?

Lastly, when revision is RevisionType::Special, what is the
format of
QString revisionValue()? Is it just int? or string such as
"Head"?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

dukju ahn wrote:
> I'm not discussing the interface. I'm asking the
usages.

Ok. These are good questions, btw, thanks for asking!

> When revision is RevisionType::GlobalNumber, then does
the
> QString revisionValue() returns the number using
QString::fromInt()??

Sounds right, so you might have e.g. "651432"
(that's a QString). Or... 
I wonder if we should standardize that between FileNumber
and 
GlobalNumber, there is a specific prefix, e.g. GlobalNumber
might always 
start with 'r' (or ''?) and FileNumber might always start with
'#'?

> When revision is RevisionType:ate,
then what is the format
> of QString revisionValue() ?

IIRC it should be a QDate-parsable string. We should
probably specify a 
standard format (which may be 'use a system-configured
format', but the 
point is we should be consistent across VCS's).

> Lastly, when revision is RevisionType::Special, what is
the format of
> QString revisionValue()? Is it just int? or string such
as "Head"?

It would be e.g. "HEAD", possibly all upper case
like that. Again we 
should standardize this.

We should also update the doc with such information.

-- 
Matthew
ESIG: .sig file not available


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/6/5, Matthew Woehlke <mw_triadusers.sourceforge.net>:
> dukju ahn wrote:
> > I'm not discussing the interface. I'm asking the
usages.
>
> Ok. These are good questions, btw, thanks for asking!
>
> > When revision is RevisionType::GlobalNumber, then
does the
> > QString revisionValue() returns the number using
QString::fromInt()??
>
> Sounds right, so you might have e.g. "651432"
(that's a QString). Or...
> I wonder if we should standardize that between
FileNumber and
> GlobalNumber, there is a specific prefix, e.g.
GlobalNumber might always
> start with 'r' (or ''?) and FileNumber might
always start with '#'?

Because we already know the type of revision by
revisionType(),
we don't need to use special format to distinguish between
filenumber
and globalnumber. Just int number will be enough

> > When revision is RevisionType:ate,
then what is the format
> > of QString revisionValue() ?
>
> IIRC it should be a QDate-parsable string. We should
probably specify a
> standard format (which may be 'use a system-configured
format', but the
> point is we should be consistent across VCS's).

Then we should use

QString QDateTime::toString ( Qt:ateForma
t format = Qt::TextDate ) const.

because with returned string, new QDateTime can be easily
constructed with

QDateTime QDateTime::fromString ( const QString &
string,
                                                       
Qt:ateForma
t
format = Qt::TextDate )

Also we should use QDateTime, rather than just QDate. There
was discussion
about datetime.

> > Lastly, when revision is RevisionType::Special,
what is the format of
> > QString revisionValue()? Is it just int? or string
such as "Head"?
>
> It would be e.g. "HEAD", possibly all upper
case like that. Again we
> should standardize this.

Oh no. If RevisionType is Special, QString revisionValue()
should return
the RevisionSpecialType enum value, which would be int.
I was silly to ask such an easy question. It was very late
night yesterday 

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 06.06.07 07:55:23, dukju ahn wrote:
> 2007/6/5, Matthew Woehlke <mw_triadusers.sourceforge.net>:
> > dukju ahn wrote:
> > > I'm not discussing the interface. I'm asking
the usages.
> >
> > Ok. These are good questions, btw, thanks for
asking!
> >
> > > When revision is RevisionType::GlobalNumber,
then does the
> > > QString revisionValue() returns the number
using QString::fromInt()??
> >
> > Sounds right, so you might have e.g.
"651432" (that's a QString). Or...
> > I wonder if we should standardize that between
FileNumber and
> > GlobalNumber, there is a specific prefix, e.g.
GlobalNumber might always
> > start with 'r' (or ''?) and FileNumber might
always start with '#'?
> 
> Because we already know the type of revision by
revisionType(),
> we don't need to use special format to distinguish
between filenumber
> and globalnumber. Just int number will be enough

No, not an int. Not all revision systems might use
"plain integer"
numbers, for example CVS has A.B.C.D.E.F.G.H... depending on
the branch
depth.

> > > When revision is RevisionType:ate,
then what is the format
> > > of QString revisionValue() ?
> >
> > IIRC it should be a QDate-parsable string. We
should probably specify a
> > standard format (which may be 'use a
system-configured format', but the
> > point is we should be consistent across VCS's).
> 
> Then we should use
> 
> QString QDateTime::toString ( Qt:ateForma
t format = Qt::TextDate ) const.

You mean we should use Qt::TextDate as type? I object. This
will be a
localized string and IMHO we should rather strive to return
UTC in a
public API.

I'm actually wondering wether we should use QVariant as
return type
instead of QString, that way we can return a QDateTime
directly. Of
course any other type of revision will need to return a
QString, even if
for example its a revision number and the VCS uses plain
ints for
numbering.

> > > Lastly, when revision is
RevisionType::Special, what is the format of
> > > QString revisionValue()? Is it just int? or
string such as "Head"?
> >
> > It would be e.g. "HEAD", possibly all
upper case like that. Again we
> > should standardize this.
> 
> Oh no. If RevisionType is Special, QString
revisionValue() should return
> the RevisionSpecialType enum value, which would be
int.

Wrong, it would be RevisionSpecialType, but if we do that
and we do the
above (which makes sense for me) then RevisionSpecialType
needs to be
registered as metatype.

Andreas

-- 
Today is the first day of the rest of your life.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/6/6, Andreas Pakulat <apakugmx.de>:
> On 06.06.07 07:55:23, dukju ahn wrote:
> > 2007/6/5, Matthew Woehlke <mw_triadusers.sourceforge.net>:
> > > dukju ahn wrote:
> > > > I'm not discussing the interface. I'm
asking the usages.
> > >
> > > Ok. These are good questions, btw, thanks for
asking!
> > >
> > > > When revision is
RevisionType::GlobalNumber, then does the
> > > > QString revisionValue() returns the
number using QString::fromInt()??
> > >
> > > Sounds right, so you might have e.g.
"651432" (that's a QString). Or...
> > > I wonder if we should standardize that
between FileNumber and
> > > GlobalNumber, there is a specific prefix,
e.g. GlobalNumber might always
> > > start with 'r' (or ''?) and FileNumber might
always start with '#'?
> >
> > Because we already know the type of revision by
revisionType(),
> > we don't need to use special format to distinguish
between filenumber
> > and globalnumber. Just int number will be enough
>
> No, not an int. Not all revision systems might use
"plain integer"
> numbers, for example CVS has A.B.C.D.E.F.G.H...
depending on the branch
> depth.
>
> > > > When revision is RevisionType:ate,
then what is the format
> > > > of QString revisionValue() ?
> > >
> > > IIRC it should be a QDate-parsable string. We
should probably specify a
> > > standard format (which may be 'use a
system-configured format', but the
> > > point is we should be consistent across
VCS's).
> >
> > Then we should use
> >
> > QString QDateTime::toString ( Qt:ateForma
t format = Qt::TextDate ) const.
>
> You mean we should use Qt::TextDate as type? I object.
This will be a
> localized string and IMHO we should rather strive to
return UTC in a
> public API.

I overlooked. You are right.

> I'm actually wondering wether we should use QVariant as
return type
> instead of QString, that way we can return a QDateTime
directly. Of
> course any other type of revision will need to return a
QString, even if
> for example its a revision number and the VCS uses
plain ints for
> numbering.

IMHO, QVariant isn't needed. We already know the type of
VcsRevision.
And QDateTime can be directly constructed using the returned
QString.

> > > > Lastly, when revision is
RevisionType::Special, what is the format of
> > > > QString revisionValue()? Is it just int?
or string such as "Head"?
> > >
> > > It would be e.g. "HEAD", possibly
all upper case like that. Again we
> > > should standardize this.
> >
> > Oh no. If RevisionType is Special, QString
revisionValue() should return
> > the RevisionSpecialType enum value, which would be
int.
>
> Wrong, it would be RevisionSpecialType, but if we do
that and we do the
> above (which makes sense for me) then
RevisionSpecialType needs to be
> registered as metatype.

Yes. it would be RevisionSpecialType. BTW, I don't
understand what is
metatype. We already defined RevisionSpecialType. Why do we
need
additional type?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 06.06.07 12:28:18, dukju ahn wrote:
> 2007/6/6, Andreas Pakulat <apakugmx.de>:
> > I'm actually wondering wether we should use
QVariant as return type
> > instead of QString, that way we can return a
QDateTime directly. Of
> > course any other type of revision will need to
return a QString, even if
> > for example its a revision number and the VCS uses
plain ints for
> > numbering.
> 
> IMHO, QVariant isn't needed. We already know the type
of VcsRevision.
> And QDateTime can be directly constructed using the
returned QString.

Well, but we could avoid one conversion step.

> > > > > Lastly, when revision is
RevisionType::Special, what is the format of
> > > > > QString revisionValue()? Is it just
int? or string such as "Head"?
> > > >
> > > > It would be e.g. "HEAD",
possibly all upper case like that. Again we
> > > > should standardize this.
> > >
> > > Oh no. If RevisionType is Special, QString
revisionValue() should return
> > > the RevisionSpecialType enum value, which
would be int.
> >
> > Wrong, it would be RevisionSpecialType, but if we
do that and we do the
> > above (which makes sense for me) then
RevisionSpecialType needs to be
> > registered as metatype.
> 
> Yes. it would be RevisionSpecialType. BTW, I don't
understand what is
> metatype. We already defined RevisionSpecialType. Why
do we need
> additional type?

See the QVariant documentation, to use a custom datatype
with QVariant
you need to register it using qRegisterMetaType and IIRC
Q_DECLARE_METATYPE (or similar).

Andreas

-- 
Time to be aggressive.  Go after a tattooed Virgo.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 06.06.07 09:27:08, Matthew Woehlke wrote:
> dukju ahn wrote:
> > 2007/6/5, Matthew Woehlke <mw_triadusers.sourceforge.net>:
> >> dukju ahn wrote:
> >>> Lastly, when revision is
RevisionType::Special, what is the format of
> >>> QString revisionValue()? Is it just int?
or string such as "Head"?
> >> It would be e.g. "HEAD", possibly
all upper case like that. Again we
> >> should standardize this.
> > 
> > Oh no. If RevisionType is Special, QString
revisionValue() should return
> > the RevisionSpecialType enum value, which would be
int.
> > I was silly to ask such an easy question. It was
very late night yesterday 
> 
> Huh? Why would you do that?
> 
> I think we need to ask what the point of revisionValue
is; my assumption 
> would be that it is to return a human-readable string
(Andreas: an 
> argument /against/ returning QVariant here), in which
case Head must be 
> translated as "HEAD" (or "Head",
"head", etc, but certainly not "1"!).

Hmm, right, the API can cope with the revision directly...
So I agree to
stay with QString and I think we should use all upper-case,
as thats
what seems to be common around VCS documentation for these
things.

Andreas

-- 
Another good night not to sleep in a eucalyptus tree.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hello!

While porting CVS plugin to our new VCS-interface 
I got stopped by VcsRevision having no implementation.

I've attached a first shot.


While implementing I asked myself, what's the deal with 
the RevisionSpecialType enum. I can't see anything using it.

Shouldn't there be something like:
void setSpecialRevision(RevisionSpecialType type);
Which will automatically set the d->type to
"Special" and 
d->revision to the appropriate string.


Robert

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gm
x.net/de/go/multimessenger

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 07.06.07 14:11:26, Matthew Woehlke wrote:
> Robert Gruber wrote:
> > While porting CVS plugin to our new VCS-interface

> > I got stopped by VcsRevision having no
implementation.
> 
> I think that's because each plug-in is supposed to
provide its own 
> implementation, because it may differ, e.g. CVS has
only FileNumber's 
> and they look different than FileNumber's in, say,
Perforce.

I think thats not going to work, unless we allocate
VcsRevisions on the heap
which I don't think we should.

Robert I didn't yet look at your implementation, but I was
planning to
get implementations for most of the vcshelpers ready by the
end of the
weekend.

> > While implementing I asked myself, what's the deal
with 
> > the RevisionSpecialType enum. I can't see anything
using it. 
> > Shouldn't there be something like:
> > void setSpecialRevision(RevisionSpecialType
type);
> 
> The intent was to provide global static instances of
e.g. HEAD, BASE, 
> etc. I don't think we ever got around to this; they
probably should be 
> listed in vcshelpers.h.
> 
> Andreas, does this look OK?

I think no. But I have to think about it a bit more...

Andreas

-- 
Your fly might be open (but don't check it just now).

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/6/6, Andreas Pakulat <apakugmx.de>:
> On 06.06.07 09:27:08, Matthew Woehlke wrote:
> > dukju ahn wrote:
> > > 2007/6/5, Matthew Woehlke <mw_triadusers.sourceforge.net>:
> > >> dukju ahn wrote:
> > >>> Lastly, when revision is
RevisionType::Special, what is the format of
> > >>> QString revisionValue()? Is it just
int? or string such as "Head"?
> > >> It would be e.g. "HEAD",
possibly all upper case like that. Again we
> > >> should standardize this.
> > >
> > > Oh no. If RevisionType is Special, QString
revisionValue() should return
> > > the RevisionSpecialType enum value, which
would be int.
> > > I was silly to ask such an easy question. It
was very late night yesterday 
> >
> > Huh? Why would you do that?
> >
> > I think we need to ask what the point of
revisionValue is; my assumption
> > would be that it is to return a human-readable
string (Andreas: an
> > argument /against/ returning QVariant here), in
which case Head must be
> > translated as "HEAD" (or
"Head", "head", etc, but certainly not
"1"!).
>
> Hmm, right, the API can cope with the revision
directly... So I agree to
> stay with QString and I think we should use all
upper-case, as thats
> what seems to be common around VCS documentation for
these things.

We already defined RevisionSpecialType as an enum. Then why
should we
return these enum values like QString("HEAD") ??

IF( RevisionType revision.revisionType() ==
RevisionType::Special )
{
    RevisionSpecialType special =
revision.revisionSpecialType()
    switch( special )
        case VcsRevision::Head:
}

So we need to add VcsRevisionSpecialType
revisionSpecialType(), then
Above concept is more natural once we defined
RevisionSpecialType enum.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel