[RFC] Workingstyle of different VCS systems

Fri Apr 6 01:15:59 UTC 2007

On Thursday 05 April 2007 11:51, Andreas Pakulat wrote:
> 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

I think we need to support tagging and branching in the interface somehow. 
Just because it's not something that developers do often, it's something we 
should support, especially if we want a "make a release, package it, and 
publish it" plugin, like we have with KDevelop 3.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070405/76cd466b/attachment.sig>