[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 12.04.07 16:43:43, Matthew Woehlke wrote:
>> Andras Mantia wrote:
>>> I doubt svn locks anything. Another user can commit in the same file 
>>> easily while you are working on it. All you get is a conflict (and an 
>>> error message on commit).
>> svn does atomic commits, therefore it has to support transactions. That 
>> means either locking, or ability to roll back partial transactions. Note 
>> that I'm talking about a lock that only lasts from when you hit enter 
>> after 'svn ci' until svn is done running, i.e. a few minutes at most in 
>> extreme cases. Perforce I /know/ works this way.
> 
> Uhm, the length of the checkin depends on the amount of data you
> checkin. I managed all the stuff for my thesis in SVN (pdf's, data,
> latex, presentations and the visio files) and some commits took quite
> some time, even on my DSL line. So it could as well be half an hour on
> extreme cases or 2 hours on low-bandwidth network.

Hmm, ok, I wasn't accounting for updating large multimdeia-like files. 
That would indeed take longer. :-)

>>>> Anyway since the ideal is to be able to write an abstract GUI using
>>>> these interfaces, we still need it in the interface. :-)
>>> Do we want such a GUI? I mean, will the plugins only do backend stuff 
>>> and not plug their actions into the user interface and instead we have 
>>> another plugin for the GUI? It doesn't really make sense because of the 
>>> differences between the VCS variants.
>> Why not? :-) One thing I get from this is that different VCS's /aren't/ 
>> that different, or at least can be easily made to seem similar enough 
>> that you can do exactly this.
> 
> Yeap, although we haven't touched distributed VCS like svk yet. (Is
> darcs also a distributed vcs?)

True, but... well I don't have experience there, but I thought a dvcs 
was sort-of like working with a local repo plus you occasionally sync 
your repo with other repos? I.e. most stuff is the same, you just *also* 
have the sync actions? (Anyone out there with dvcs knowledge?)

>>> Doing the diff is usually an operation from the GUI. When would you do a 
>>> diff from a 3rd plugin or a script?
>> We're not talking about only scripts, we're also talking about KDevelop. 
>> Why should I not be able to click on a file I am working on and say 'how 
>> is my working copy different from the latest repo copy?'. Would you 
>> prefer to have to leave KDevelop and go to some other application (or a 
>> command line) to do this?
> 
> Well, but this would be done through the context menu of the file and
> the context menu is filled by the plugins.

"file" = "file's context menu" :-)
I think we are talking about the same thing. If the interface with 
diff() is implemented, the objective is for KDevelop to add that to the 
context menu, right? So in this instance the plug-in says "I implement 
diff()", and KDevelop asks if it does and then adds "Diff...", yes? IIUC 
things that don't have an interface are added explicitly by the plugin.

> We already have the backends re-inventing the wheel. At least thats what
> the last commits to cvs looked like, i.e. not using the outputview
> anymore.

True, but we're still beating on this, I trust/hope that when this is 
settled we will make cvs use it. :-)

> For aegis we need to extend KTextEditor I think, because SaveAs asks the
> user for the filename, we'd need a SaveAs that takes a KUrl.

Ack! I wasn't aware that you can't tell KTE where to save a file. That 
needs to change, and not just for KDevelop but IMO because it's an 
interface that should just exist on its own merit.

-- 
Matthew
Current geek index: 62%