[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 05.04.07 11:08:43, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 05.04.07 09:58:28, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >>> cleanup - fix inconsistencies with the local checkout
> >> Hmm... since I have never used anything like this, I can't tell you. 
> >> What would this do?
> > 
> > Well, for svn I had to use this a couple of times, specifically when
> > interrupting a commit while it transfers data. There were some other
> > occassions but I can't remember exactly what they were. This is
> > something that is user-initiated if the vcs says: "Hey, somehow I
> > screwed my "working-copy", please fix me".
> 
> Ok, well in perforce there is 'sync -f' which says 'unconditionally 
> download everything in the workspace' (I forget, it may even clobber 
> opened files also). Maybe that is similar?

I'm not sure. What cleanup does in the svn case is fix broken stuff in
.svn: 
andreas at morpheus:~>LANG=C svn help cleanup
cleanup: Recursively clean up the working copy, removing locks, resuming
unfinished operations, etc.

> >> Perforce has a good bit of stuff that needs to be added in addition to 
> >> the generic list. For instance with p4 you manage changelists, you have 
> >> a 'default' one but you can also move files to other changelists that 
> >> can have their descriptions set in advance. This makes it easy to work 
> >> on multiple change sets because you don't have to tell the VCS what 
> >> files you do or do not want to check in so often. Also it is an 'edit' 
> >> based system, i.e. you have to 'open for edit' files that you want to 
> >> change.
> > 
> > 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.
> 
> (* you can chmod +w a file yourself, but perforce won't know you are 
> editing it unless told, so it will never be committed. This can be a 
> "feature", or a PITA :-).)
> 
> 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...

> >> Maybe you should add an interface for all "common" actions (like 
> >> property editing) but allow VCS plugins to specify which ones they 
> >> support, and hide the others. In that case I would add to the list 
> >> property editing and opening a file for edit.
> > 
> > You can subclass interfaces to add more specific methods. So the general
> > one should provide only those things that all VCS we consider
> > supportable have in common (at least to a certain extent).
> 
> The reason I suggested it was to provide naming consistency for actions 
> that are common but not universal. Otherwise two back ends might wind up 
> with different names for equivalent actions.

I think we mean the same thing: Providing a IVersionControl which
provides stuff like add/remove/copy/... but leave stuff thats only
available in 1 or 2 specific VCS systems to a subclass of
IVersionControl for that specific VCS.

> >> What about support for tagging [snip]
> > 
> > Well, this is largely different between CVS and SVN already - AFAIK -
> > which means: No. The various VCS plugins may choose to provide this via
> > context menu actions, but I don't see the need for this in the
> > vcs-iface.
> 
> Agreed. IMO KDevelop front ends should not support it at all, I think 
> it's a task more suited to a stand-alone vcs client.

Well, it might be nice if you work on a project in kdevelop and decide:
I just fixed the 100th bug in my .0 version, lets tag a new release to
be able to do that from within kdevelop. So SVN could do something like:
right-click project->Tag New Version->input repository url for tags +
new dirname for tagged version (i.e. 1.0.1) -> execute. Which would just
do a svn copy on the svn server. I have no idea how CVS handles
tagging...

> >> However I am also thinking that it would be ideal to put all of this
> >> in a lib in a way that would allow it all to be used by other
> >> applications, for example a stand-alone dedicated vcs application that
> >> would use the same back-ends would rock
> > 
> > Well, if we use standard widgets for parts of this, we're going to
> > provide a libkdevplatformvcs. So a possible VCS-only app could start on
> > top of kdevplatform, however I don't think anybody here wants to start a
> > new kdevcs-lib project unless you do :)
> 
> I think this became a question of 'where does it live'. I don't see any 
> reason a generic VCS client can't depend on kdevplatform (assuming I am 
> remembering correctly that this means it depends on the kdevelop module, 
> not the kdevelop application).

It kdevplatform module, but yes thats what I meant. Basically everything
in lib/ will be split out into a separate module, once we have the last
things sorted out there (which currently includes lang-support, vcs and
config IIRC)

Andreas

-- 
You may be gone tomorrow, but that doesn't mean that you weren't here today.