[RFC] Workingstyle of different VCS systems
Andreas Pakulat
apaku at gmx.de
Thu Apr 5 19:05:01 UTC 2007
On 05.04.07 13:04:43, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 05.04.07 11:08:43, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >> [snip]
> >> 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.
>
> Hmm... ok, I guess it's similar. I don't know how aegis works, so... :-)
See the archive of last month, Kuba Ober tried to explain it to me.
> > 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...
>
> No, this is totally unnecessary/wrong with perforce. Most opening files
> is "look, don't touch"; edit should be a separate action. Alternatively,
> if you could intercept trying to save a file, and if it is -w, /then/
> pop up a dialog asking if you want to open it for edit, that would rock.
> But files should not be opened for edit when you open them.
Hmm, I'm not sure we can intercept it (I haven't looked at the
kate-integration).
> >>>> 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. [snip]
>
> Well, it's just MHO but tagging to me is a more complicated action that
> you need to take more care in doing than something I think I personally
> would want to put directly in KDevelop. Also it isn't as "directly" in
> the work flow as editing, committing, and even renaming, it is more "off
> to the side". But that's just MHO.
Well, I think it depends. On a large project like KDevelop its certainly
not apropriate, however if you're working on your own small project that
you do release sometimes it might be convenient to not have to switch to
another client. As I said I don't know about other VCS' but with svn its
just a plain svn copy and thats pretty easy.
> >> 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. [snip]
>
> Ok, like I said the point is just to make a stand-alone application and
> not a KDevelop plugin, i.e. I don't want to have to run KDevelop to run
> "FooVCS GUI Client". :-)
Well, your client would more or less only leverage the platform+the
various VCS plugins available. The actual client code would eventually
be rather small...
Andreas
--
What happened last night can happen again.
More information about the KDevelop-devel
mailing list