[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 05.04.07 16:00:49, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 05.04.07 15:01:58, Matthew Woehlke wrote:
>>>> Andreas Pakulat wrote:
>>>>> On 05.04.07 13:04:43, Matthew Woehlke wrote:
>>>>>> Hmm... ok, I guess it's similar. I don't know how aegis works, so... :-)
>>>>> See the archive of last month, Kuba Ober tried to explain it to me.
>>>> I know, I've been reading, but I didn't understand it either. :-)
>>> Good :) I already thought I'm stupid. Although I have to admit that I
>>> don't completely understand the "workflow" in perforce either :)
>> Eh, perforce is easy. :-) It's almost exactly like svn except you have 
>> to 'p4 edit' before you can edit. And you have clients to map files from 
>> the repo to your workspace instead of what amounts to a symlink to the 
>> repo (i.e. you get exactly the entire tree, no more no less),
> 
> Symlink to the repository?? Which VCS does that stupidity?

The point was that you checkout some path, and you get that path, that 
/whole/ path, and nothing /but/ that path. Sort of like making a symlink 
to somewhere else on your system; when you cd to the symlink, you get 
all the content from there and nothing but the content from there. 
Apologies if the analogy fell flat. :-) Perforce is more like rsyncing 
with multiple target mappings and also exclusion rules.

>> but that doesn't really change the workflow, just makes it easier
>> (possibly? ;-)) to be selective about what you pull down.
> 
> Well, thats something svn does allow too, although if you're not
> watching your fingers you easily checkout the whole of a project.

Mmm, well, yeah, I kinda-sorta got it to work once, but as you say, svn 
really isn't designed for it (not yet, anyway), you're doing some pretty 
funky stuff to get it to... "work" (and I use the term somewhat loosely).

>> and there was something about all sorts of 
>> weird stuff you have to do with symlinks and... I admit I didn't read it 
>> *real* closely but it sounded really strange. :-)
> 
> No, the symlinks are there to be able to compile inside a changeset, as
> there are only few files in there not the whole project. But normal
> buildsystems like qmake/cmake/make/whatever need the whole project.

Yeah, you can tell I re-read the thread first, yes? ;-) I mainly 
remember what you just said, there are strange things you have to do to 
use normal build systems.

>>>>> Hmm, I'm not sure we can intercept it (I haven't looked at the
>>>>> kate-integration).
>>>> Offhand I would guess you can't, but IMO that's OK.
>>> Well, now is the time to ask kate-devs to get this...
>> We really need it in KTextEditor though, don't we? I'm happy to ask if 
>> you think it's worthwhile.
> 
> Well it can't hurt...

Ok...

>> Or is KDevelop4 dropping KTextEditor support?
> 
> No, at least not as long as kate-devs still call it KTextEditor ;)

:-)

...but the question was, isn't the point of KTextEditor to allow other 
back-ends? I admit I'm not very familiar with the module ownership here, 
but, while KATE obviously has to support such an interface extension, 
does KATE also own the interface definition, or would that be a topic 
for k-c-d?

>> Yes, that sounds like perforce's "labels". I'm unconvinced of the 
>> importance of trying to support that directly in KDevelop (I'm not 
>> arguing against it, really, I'm just unconvinced).
> 
> Well, we'll leave it to the vcs plugins anyway, so they can decide...

Agreed. I don't care what the individual plug-ins want to try to 
implement. :-)

>> Would svn have separate interfaces for "branch" and "tag", even though 
>> they do the same thing under the covers? Other VCS back ends would need 
>> them to be separate.
> 
> Uhm, SVN doesn't have an interface at all for branch or tag. You handle
> a SVN repository just like a normal filesystem. So you literally copy a
> branch at a specific revision to a tag:

Right, I was kind-of assuming that "branch" and "copy" were already 
synonyms.

This brings up the interesting point, however, that my personal 
inclination would be to label the menu item "copy/branch"... because the 
way I think about it there really is no "copy" in VCS because a "copy" 
*is" a "branch". :-)
> Anyway, as I said above, both branching and tagging should be left to
> the vcs plugin. I don't see the need for this to be in the common VCS
> interface.

Hmm, there I disagree, branching is pretty fundamental, I would prefer 
to see that in the common interface. Wasn't the original post 
suggestions for the common interface, or did I mis-read somewhere?

Back to the original topic, I would make the common interface:

add (dir, non-recursive might be a no-op)
edit (optional: VCS can specify if this is enabled)
copy
delete
move
revert
properties

state
commit
update

diff
log
blame
file_version
info

merge
resolve

One way to have shared optional interfaces might be to do something like 
standard actions, that is something using the plug-in can query if it 
supports a standard action, and back ends would add standard actions 
that they support. In fact you could take this all the way and have a 
totally empty generic interface. If we had such standard actions then 
these would be good candidates:

tag
lock
unlock
view (look at an arbitrary file in the repo)
viewrev (look at an arbitrary revision's changelog and optionally diffs)

...'mkdir' IMO shouldn't be a VCS action, if there is a 'mkdir' in 
KDevelop it should have a check box 'add to repo' that would do a 
non-recursive add.

I'm on the fence about 'repo_version', 'ignore' and 'cleanup', if you 
want them in a standard interface that's fine but IMO the latter two 
should be optional. I'd also be OK omitting them, however.

'edit' is prickly because anything using the abstract VCS interface 
should be able to quickly query if it is there or not. I almost want to 
say it would be best for all VCS to have it (as a no-op where not 
needed), and always call it when appropriate even if it is empty.

-- 
Matthew
<insert bad pun... on second thought, better not>