[RFC] Workingstyle of different VCS systems

Matt Rogers mattr at kde.org
Fri Apr 6 00:20:12 UTC 2007


On Apr 5, 2007, at 8:06 AM, Andreas Pakulat wrote:

> Hi,
>
> before I propose an update on the VCS interface I'd like to get  
> people's
> experience with VCS systems. I have myself good experience with CVS  
> and
> SVN but those two are pretty similar. I also used ClearCase about 3
> years ago but don't recall the exact details.
>
> So currently we're aiming for something like this:
>
> add - adds a resource to the VCS
> remove - removes a resource from the VCS
> checkout - fetch "something" from the VCS into a local dir
> import - import a local dir into the VCS
> 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
> commit - let the VCS transfer local changes into the VCS
> update - fetch latest changes from VCS into local dir
> log - Show a complete history for a given local resource or VCS  
> resource
> diff - show a difference between local file and latest VCS version,  
> or 2
>        VCS versions
> annotate - ==svn-blame, AFAIK, i.e. show which line of a file was
>            modified by whom in which version
> repositoryVersion - gives the latest version in the repository
> localVersion - gives the version of the local file
> merge - merges differences between 2 sources into the local file
> addignores - set information which files should be ignored by the VCS
> revert - reverts local changes
> cleanup - fix inconsistencies with the local checkout
> copy - copy a file with VCS methods (history is kept)
> move - move/rename a file with VCS methods (history is kept)
> info - Show some info of the local checkout
> mkdir - create a new directory in the local checkout and add it to the
>         VCS
> resolve - mark a conflicted file as resolved
> lock/unlock - lock a file or VCS resource
> special - this should be available so clients may execute special
>           actions for a specific VCS system
>
> Do other VCS systems need other actions? Is there stuff that cannot be
> mapped to other VCS systems?
>
> Andreas
>
>

push and pull (or clone, in git's case) actions need to be covered,  
for distributed systems such as git and svk.
--
Matt






More information about the KDevelop-devel mailing list