[RFC] Workingstyle of different VCS systems
Andreas Pakulat
apaku at gmx.de
Thu Apr 12 21:01:20 UTC 2007
On 12.04.07 21:21:25, Andras Mantia wrote:
> On Thursday 05 April 2007, Andreas Pakulat wrote:
> > checkout - fetch "something" from the VCS into a local dir
> I doubt we need this in the menus, but makes sense to have in the
> interface when creating new projects (you might be able to create a new
> project directly from the repository).
Thats the purpose of this, right.
> > import - import a local dir into the VCS
> If we do not map the interface 1:1 to the VCS commands, I suggest to
> merge this action with the "add" one.
Uhm, right and import doesn't exist for some SCM's.
> > state - get the state of a local file, currently possible state flags
> > are:
> > Added, Uptodate, Modified, Conflict (between VCS-version and
> > local version), Sticky (some CVS thing, no idea what it means),
> > NeedsPatch (what does that mean?), NeedsCheckout, Directory,
> > Deleted, Replaced
> Maybe useful from a script, I don't see what you could do with this in a
> plugin's code.
Show the files in different colors for example. So the project view
would show VCS controlled files in blue and those that have been changed
in red for example. Or it could overlay an vcs-state-icon.
> > commit - let the VCS transfer local changes into the VCS
> > update - fetch latest changes from VCS into local dir
> This is normal to have, but IIRC ClearCase needs a lock before changing
> the file, so maybe automatically lock before commit and unlock after it
> (and remove th lock/unlock actions)?
Either that or that + lock/unlock in an extra interface for
SCM's that support locking.
> > move - move/rename a file with VCS methods (history is kept)
>
> Same here. I have the feeling that this copy/move shouldn't be in the
> interface.
Or at least not in the basic interface.
> > info - Show some info of the local checkout
>
> I think this is GUI only stuff.
A script could use the output of this, for example the url or
revision...
> Regarding the need of an "edit" action before actual edit, this could be
> done the following way: the framework could have a
> signal "documentAboutToOpen" to which the VCS plugin listens and do
> what is needed to allow the editing. Similar signal could be
> an "aboutToSave" or "documentSaved" which can be used to create scripts
> that automatically commit your changes on save. This is weird, but
> might make sense. This is a little OT for the thread, but we will need
> such signals in other places as well to have the so called "event
> actions" feature from Quanta (you can assign actions -execute
> scripts/integrated actions, log the event, send email - to certain
> events like those I wrote up there).
So Kate does offer such stuff already? Or how is this done in Quanta3?
Are the actions executed only after save?
Thanks for taking the time reading this thread.
Andreas
--
Learn to pause -- or nothing worthwhile can catch up to you.
More information about the KDevelop-devel
mailing list