Version: (using KDE KDE 3.1.4) Installed from: Unspecified Compiler: n/a n/a OS: Linux I would like to have a KIO slave that lets me check in koffice documents to CVS or SVN (subversion). For collaboration groups it is very important to save their text (not only source code) documents in a central place. I see it a little inconvenient to use cervisia as an extermal application, a checkout and submit should be far easier and as transparent as possible.
There is a KIO slave for subversion in kdenonbeta (kio_svn) which you might want to take a look at.
Subject: Re: WISH: KIO CVS slave, good for koffice documents Hi Christian, yes, that's kind of cool. I will observe it and see if this is what I am looking for. The whole issue of application-independent, integrated version control is really a cool thing which M$ cannot integrate as they will risk to kill the commercial version control market. For them a sophisticated integrated and groupware-enabled document management is quite a challenge. For "us" it's another cool reality ;-) The next question is: Does SVN provide a search interface to a really cool and sophisticated search engine? But this thread is no longer KDE related... Cheers, Markus On Wed, 19 Nov 2003, Christian Loose wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=68543 > > > > > ------- Additional Comments From christian.loose@hamburg.de 2003-11-19 17:30 ------- > There is a KIO slave for subversion in kdenonbeta (kio_svn) which you might want to take a look at. >
Would be nice to add CVS support to konqueror just like TortoiseCVS http://www.tortoisecvs.org/ with Windows Explorer.
Hi Jonny, there is already CVS support in konqueror. You have to install cervisia and then you can use it as plugin in konqueror, e.g. by "View" -> "View Mode" -> "CVS Frontend". Best wishes, Arne
Hi Arne. I think Jonny would like an integration with file view. Now, in cervisia view mode is not possible to move or copy files by drag icon to another directory, or view other properties, or open file in embedded viewer, for example. Also for me is very interensting to merge file view (context menu, toolbar) automatically when a CVS directory in detected, for updating repository without change view to another application. In other words CVS-Frontend is embedded, but not integrated.
*** This bug has been confirmed by popular vote. ***
Theses wishes talk about the same problem http://bugs.kde.org/show_bug.cgi?id=65311 (cervisia) http://bugs.kde.org/show_bug.cgi?id=102926 (konqueror) I think that the solution is not a new kio-slave (cvs:/..), but a integration in file view.
I thought about omitting the checked out working copy. Just skip this step. Imagine, you open a directory, let's say even with "svn://user@host/project/" and you can - generate / save files just in there from within any kde application - drag & drop files into there - open files from there and so on. I thought about integrating version control and the desktop. So that we have something like the oracle cmsdk where you save data transparently into an easily accessible file space and the backend does the versioning / version control on top.
The solution that I want to propose is different, markus. When we use url in the type "fish:/ ..", "smb:/..", "lan:/.." we refer to a remote directory. A cvs directory is a *local* directory, that we can syncronize with a remote repository. The url of each file keep "file:/...". Is not correct to have 2 different types of url for the same file. I think is better to open file in the local directory in *normal file view*, adding cvs buttons in toolbar, and change context menu (mouse right key) by detecting and reading information in the "CVS" directory. The view should be change effectively when we want to see the graph of the versions history.
Alessio, well, why not... Anyway, we should offer transparent versioning to all applications that make use of the KDE infrastructure with ressource abstraction. This is a highly useful and enterprise-class feature and something M$ cannot offer due to its monopoly. How it will be implemented is a different question. I just want to be able to - for instance - start kword and write a document and - open the file dialog through "save as" - select not the regular file system but the versioning repository (which might also be default in some enterprises) - save and do an autocommit without further requiring *me* dummy end user to think about versioning tools Best wishes, Markus
I agree, Markus. But I think is not impossible to achieve the top result. To explain further difference between solution that I proposed and kio slave solution, I present this situation: could it be possible to have a directory in a remote host; suppose that we can access this directory by ssh protocol, and this directory is also a local copy of a CVS repository: then we can access this directory with a konqueror window, by fish, and by detecting automatically cvs information, login to cvs remote repository. By context menu we update our files, and we access to history graph, to compare different versions with a graphic diff.
Dear Alessio, As I said, my intention is to bring versioning to those people who don't know what versioning is and who are not in the least interested to learn about versioning. Versioning for non-technical users... This is the way M$ would do it and earn millions. We must be faster than M$ and bring these features to the users - but make the usage as easy as M$ would do it. Thus said, I am critical about re-implementing all those cmdline switches that come along with the svn binaries. I would like to have something dumb stupid simple. Something every grandmother can use. I mean, nothing against grandmothers, grannies are wonderful and absolutely respectable women! ;-) This is the reason why I suggested a kio slave - it integrates into every kde based program and is very transparent in use. In order to avoid redundancy I thought about omitting the working copy and providing direct access to the latest release through the KIO Slave. Submits would be granular on every file upload (the release number would be increased with every save operation) Rollbacks and retrieval of past versions would not be possible with this KIO slave. The slave would just focus the latest release. (This is also how Oracle CMSDK based versioning works) Instead, rollbacks and past-versions operations could be performed with an ordinary Konqueror plugin with context sensitive or other menu options or with a standalone application like cerevisia or whatever. Rollbacks aren't made every day and only in cause of troubles. Through the granularity as proposed (submit on every save operation), greater merge operations would be rare.... Though, diff comparisons and the like would work as you said. -- But I still would like to avoid the working copy... Do you think, this scenario is realistic? I hope we will soon find a realistic and highly usable scenario...! :-) Best wishes! -- Markus
Dear Markus I understood your proposal (maybe). But I think that a working copy is important: it may be transparent to grandmothers ;-), implemented as a "off-line copy" or "cache" style, synchronizable in manual (for expert users) or automatic way (Do you know cached-imap kmail feature ?). However, I think in versioning systems it's important the use of a common repository with a concurrent version system, for teams collaboration purpose. Besides login service to attribute each modify to a user is important. In your proposal are these features lost ? I don't understand if our proposals focus different problems. Thanks!!
Dear Alessio, Well, I asked myself, why a working copy should make sense. Technically speaking we should easily be able to implement on-the-fly checkout, making the concept of a working copy absolutely obsolete. Though, there is a point: It makes sense if you have a greater number of files that belong to one single project - like code. And if you share this code among collaborating group members where everybody can make changes but in order to run the individual programmer relies on all files to have a certain, defined version. Since I was nevertheless thinking to keep this technology transparent to all sorts of applications, including programming, there needs to be another solution to it. I have seen that the file dialog in KDE 3.4.0 contains a new aggregate: "Storage Media". Since a working copy is a very special storage medium, this could be a way to develop some kind of transparent versioning. What do you think? Best wishes! - Markus
Hi Markus. Mmm, I don't like the view of working copy like a storage medium. I explain: From our discussion, in my opinion, two different ideas results: a simple, automatical and transparent versioning system for local (or not) files, easy to use, and a different advanced system for remote repository. Two idea may be the same, if we consider commit-on-each-save-operation and on-the-fly-update politics, as you propose. However I have 2 problems: 1- Remote repository: we must consider that in the real world connections are not always reliable ! A local working copy may be important to can view documents in off-line mode. But it's possible to implement a transparent caching mechanism for remote files. Little problem. 2- Now, the hard problem: I'm working to a official documentation, in a cvs repository. There are many different teams corresponding to many different partners. Each commit means a "official release", important for partner reputation, however is a partial modify for a "becoming" document. In this sense saving files and committing files are semantically very different operations. My solution: two distinct versioning systems: remote repository, with explicite committing operations, and defalut versioning systems for all files (local). If I save my local file in my working directory, the *normal* versioning system manage local versions, and by committing, we create a distinct version (with different numbering), to remote repository. From the *file view* we will can access to both versions: for instance, "myfile.tex" may be 1.7 local version, but remote version committed by me may be 1.3 for all remote users, corresponding to my 1.5 local version. If we want to commit the new version (my 1.7), the new 1.6 remote version will be the same of my 1.7 version. In this way, i can also work in off-line mode, with the *normal* versioning system. It's obvious that the normal versioning system always work. Do you like it ? Alessio.
Dear Alessio, > My solution: two distinct versioning systems: remote repository, with > explicite committing operations, and defalut versioning systems for all > files (local). If I save my local file in my working directory, the > *normal* versioning system manage local versions, and by committing, we > create a distinct version (with different numbering), to remote repository. > From the *file view* we will can access to both versions: for instance, > "myfile.tex" may be 1.7 local version, but remote version committed by me > may be 1.3 for all remote users, corresponding to my 1.5 local version. If > we want to commit the new version (my 1.7), the new 1.6 remote version will > be the same of my 1.7 version. In this way, i can also work in off-line > mode, with the *normal* versioning system. It's obvious that the normal > versioning system always work. OK, you are right. Well, I was inspired by the idea of rewinding a document to its beginning even though the editor has been exited several times. Modern WinWord can only flip backwards to the moment when it has been started. I would like to be able to track all the changes through all the previous editing sessions. I agree, there is a good reason to have versioning as we have it with subversion and so on for group development. And I see that what we need is a second (private) versioning system, possibly on top of it, working completely on the local copy. Something that does a commit on every save operation, but not to the *real* svn repository, but only to the local working copy. Sounds reasonable to me :-)) But what's the right place in the kde architecture for such a thing? Is a KIO slave the right thing? Best wishes, - Markus
Seems unlikely now that git has taken over the world.