[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 05.04.07 15:01:58, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 05.04.07 13:04:43, Matthew Woehlke wrote:
> >> 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.
> 
> I know, I've been reading, but I didn't understand it either. :-)

Good :) I already thought I'm stupid. Although I have to admit that I
don't completely understand the "workflow" in perforce either :)

> >>>> 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...
> >> 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).
> 
> Offhand I would guess you can't, but IMO that's OK.

Well, now is the time to ask kate-devs to get this...

> I'd say let's stick 
> with a manual 'edit' action, at least for perforce (maybe aegis wants to 
> do this differently).

Well, for aegis as far as I can tell you need to execute an aegis
command to get the file into the local changeset and can then edit it.
IMHO this means a context menu entry, although automatic would be
cooler...

> >> 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.
> 
> Hmm... ok, then maybe what I am thinking of as "tagging" is not what you 
> are thinking of as "tagging". It sounds like you are thinking of what I 
> call "branching".

Well, I'm spoiled by svn, because I never did this particular thing in
CVS. Unless I'm totally mistaken in CVS if you tag something its the
same as "giving a specific revision in a specific branch a name". In SVN
however there are no such "special names", normally you use a structure
like this:

project/trunk
project/branches
project/tags

trunk is self-explanatory, branches is for working branches as well as
stable releases, i.e. we have branches/KDE/3.5 for KDE 3.5. Now if you
do a release you do that from branches/KDE/3.5 at a time where you think
its ready for a .x release. You do this by copying branches/KDE/3.5 to
tags/KDE/3.5.1 (for x=1), thats it. Now you can always access KDE 3.5.1
at tags/KDE/3.5.1. Which was created from revision 564234 (whatever it
was exactly) of branches/KDE/3.5.

So I think you agree we are talking about the same thing, just that I'm
used to copying-to-tag and it seems perforce does a tag==special-name
for a revision. 

Andreas

-- 
You never hesitate to tackle the most difficult problems.