[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

(Kuba Ober, we would like your thoughts too!)

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. :-)

>>>>>>> Sounds a bit like aegis which Kuba uses... So if you have a number of
>>>>>>> files in your changelist you can't just edit them? You have to do this
>>>>>>> via a p4 command?
>>>>>> 
>>>>>> Um, I'm not sure I follow you. You "can't"* edit a file unless you open 
>>>>>> it for edit. Once it is open, you can move it around your open 
>>>>>> changelists. An open changelist basically just serves to keep track of 
>>>>>> different things you are working on at once, mainly you can pre-enter 
>>>>>> the description and you commit single changelists, so this makes it easy 
>>>>>> to commit some files but not others.
>>>>>> [snip asterisk]
>>>>>> The main practical impact here is that before you can hack on a file you 
>>>>>> have to "open" it (vcs'd files are usually -w until you open them). 
>>>>>> Changelist management I think is unique enough that it can be left to 
>>>>>> the front end to worry about.
>>>> 
>>>> Yes, thats exactly what I was thinking, i.e. you can't just click on a
>>>> file in the project which opens it and then edit it. You first have to
>>>> execute some vcs-action to do that.
>>> 
>>> As aegis needs something similar I think we should try to find a way to
>>> execute some vcs-action before opening a file in the editor...
>> No, this is totally unnecessary/wrong with perforce. Most opening files 
>> is "look, don't touch"; edit should be a separate action. Alternatively, 
>> if you could intercept trying to save a file, and if it is -w, /then/ 
>> pop up a dialog asking if you want to open it for edit, that would rock. 
>> But files should not be opened for edit when you open them.
> 
> 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. I'd say let's stick 
with a manual 'edit' action, at least for perforce (maybe aegis wants to 
do this differently). Anyway I think we are again drifting into back end 
implementation and away from interface design. :-) I guess maybe we 
should keep in mind that a VCS plugin may want to hook certain events 
(maybe Kuba Ober could comment on this?).

>> Well, it's just MHO but tagging to me is a more complicated action that 
>> you need to take more care in doing than something I think I personally 
>> would want to put directly in KDevelop. Also it isn't as "directly" in 
>> the work flow as editing, committing, and even renaming, it is more "off 
>> to the side". But that's just MHO.
> 
> Well, I think it depends. On a large project like KDevelop its certainly
> not apropriate, however if you're working on your own small project that
> you do release sometimes it might be convenient to not have to switch to
> another client. As I said I don't know about other VCS' but with svn its
> just a plain svn copy and thats pretty easy.

Hmm... ok, then maybe what I am thinking of as "tagging" is not what you 
are thinking of as "tagging". It sounds like you are thinking of what I 
call "branching". I'd be OK supporting that in the VCS interface. In 
perforce there are also "labels" which are a combination of a client and 
a revision number. So if you have /branches/3.5, you might have labels 
"3.5.0", "3.5.1", "3.5.2", etc, that correspond to a particular release. 
This might be "3.5.2 is /branches/3.5/... at revision 5127".

What I am thinking of as "branching" would be e.g. creating 
/branches/4.0 containing the contents of /trunk.

>> Ok, like I said the point is just to make a stand-alone application and 
>> not a KDevelop plugin, i.e. I don't want to have to run KDevelop to run 
>> "FooVCS GUI Client". :-)
> 
> Well, your client would more or less only leverage the platform+the
> various VCS plugins available. The actual client code would eventually
> be rather small...

Right... that's the idea. :-)

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