VCS Ifaces copy/move/update/log problem.

Hi.

This thread is restricted only to copy/move/update/log

1. I've just found out that subversion doesn't support
recursive/non-recursive selections for
IBasicVC::copy(), move()

In subversion, these two are always recursive. There is no
flags
to set recursive/non-recurse.

2. in IBasicVC::update(), how about specifying revision as
an argument?
Updaiting to specific revision is very useful, especially in
case when
the HEAD contains compile erros.

3. IBasicVC::log() should have revision or revision range.

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

On 04.05.07 13:31:11, dukju ahn wrote:
> Hi.
> 
> This thread is restricted only to copy/move/update/log
> 
> 1. I've just found out that subversion doesn't support
> recursive/non-recursive selections for
> IBasicVC::copy(), move()
> 
> In subversion, these two are always recursive. There is
no flags
> to set recursive/non-recurse.

Hmm, that is a problem indeed. You can't emulate that
without loosing
history. 

Matthew: any objections against making copy/move always work
recursive
on a directory? Else we'd have to add a clear comment to the
API that
move/copy might ignore the recursion parameter if the VCS
doesn't
support it.

> 2. in IBasicVC::update(), how about specifying revision
as an argument?
> Updaiting to specific revision is very useful,
especially in case when
> the HEAD contains compile erros.

Agreed, from me.

> 3. IBasicVC::log() should have revision or revision
range.

Yeap. I thought I already had that in an earlier version.

Andreas

-- 
You have many friends and very few living enemies.

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

dukju ahn wrote:
> 1. I've just found out that subversion doesn't support
> recursive/non-recursive selections for
> IBasicVC::copy(), move()
>
> In subversion, these two are always recursive. There is
no flags
> to set recursive/non-recurse.

Ok, right now there is no recursion flag anyway. Anyone feel
it is a 
problem if copy()/move() are always recursive if given a
directory? (I 
don't see why they shouldn't be...)

> 2. in IBasicVC::update(), how about specifying revision
as an argument?
> Updaiting to specific revision is very useful,
especially in case when
> the HEAD contains compile erros.

Yike! Thanks for catching that... update committed.

> 3. IBasicVC::log() should have revision or revision
range.

I'm waiting to see what Andreas says about having two
flavors of 
log()/showLog() before committing an update. A starting
revision and 
advisory limit will be added as parameters to log().

I don't think showLog() should have a limit (I do plan to
add a starting 
revision); the UI can use a default limit with incremental
updates (or 
more preferably, work with log() that supports incremental
retrieval of 
the results).

-- 
Matthew
Current geek index: 62%


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

Andreas Pakulat wrote:
> On 04.05.07 13:31:11, dukju ahn wrote:
>> 1. I've just found out that subversion doesn't
support
>> recursive/non-recursive selections for
>> IBasicVC::copy(), move()
>>
>> In subversion, these two are always recursive.
There is no flags
>> to set recursive/non-recurse.
> 
> Hmm, that is a problem indeed. You can't emulate that
without loosing
> history. 

I think the usual method is either to not copy the
directories (i.e. do 
files one at a time) or nuke what you don't want later. This
should work 
for IBasicVC (since the copy isn't committed immediately).

> Matthew: any objections against making copy/move always
work recursive
> on a directory? Else we'd have to add a clear comment
to the API that
> move/copy might ignore the recursion parameter if the
VCS doesn't
> support it.

Mails waving at each other as the pass, again.  No
objection, and 
actually the ifaces already don't have a recursive
parameter. Oh, 
wait... only in IRepoVC they don't. So, nuked in IBasicVC as
well.

However... this brings up another omission, I think IRepoVC
actually 
needs copy() and showCopy() because these are doing a
commit() under the 
covers. Yes? No?

>> 2. in IBasicVC::update(), how about specifying
revision as an argument?
>> Updaiting to specific revision is very useful,
especially in case when
>> the HEAD contains compile erros.
> 
> Agreed, from me.

Already fixed. 

>> 3. IBasicVC::log() should have revision or revision
range.
> 
> Yeap. I thought I already had that in an earlier
version.

I don't remember it, but if it got nuked accidentally, my
apologies. 

-- 
Matthew
Current geek index: 62%


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

On 04.05.07 13:32:29, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 04.05.07 13:31:11, dukju ahn wrote:
> >> 1. I've just found out that subversion doesn't
support
> >> recursive/non-recursive selections for
> >> IBasicVC::copy(), move()
> >>
> >> In subversion, these two are always recursive.
There is no flags
> >> to set recursive/non-recurse.
> > 
> > Hmm, that is a problem indeed. You can't emulate
that without loosing
> > history. 
> 
> I think the usual method is either to not copy the
directories (i.e. do 
> files one at a time)

Well, I thought about perforce here (in svn its always
recursive) isn't
it possible to just copy a dir with the files in it to some
other place?
If you want to do it on a per-file basis you first have to
mkdir+add the
new dir, which means loosing some history. Although I guess
its more
important to keep the file's history...

> > Matthew: any objections against making copy/move
always work recursive
> > on a directory? Else we'd have to add a clear
comment to the API that
> > move/copy might ignore the recursion parameter if
the VCS doesn't
> > support it.
> 
> Mails waving at each other as the pass, again.  

hehe

> No objection, and actually the ifaces already don't
have a recursive
> parameter. Oh, wait... only in IRepoVC they don't. So,
nuked in
> IBasicVC as well.

Fine.

> However... this brings up another omission, I think
IRepoVC actually 
> needs copy() and showCopy() because these are doing a
commit() under the 
> covers. Yes? No?

Doesn't it have copy() already? I thought so, well I agree
here. And
copy() needs to take a commit message of course.

Andreas

-- 
Today is the tomorrow you worried about yesterday.

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