Re: Workingstyle of different VCS systems

(Kuba Ober, we would like your thoughts too!)

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. 

>>>>>>> Sounds a bit like aegis which
Kuba uses... So if you have a number of
>>>>>>> files in your changelist you
can't just edit them? You have to do this
>>>>>>> via a p4 command?
>>>>>> 
>>>>>> Um, I'm not sure I follow you. You
"can't"* edit a file unless you open 
>>>>>> it for edit. Once it is open, you
can move it around your open 
>>>>>> changelists. An open changelist
basically just serves to keep track of 
>>>>>> different things you are working on
at once, mainly you can pre-enter 
>>>>>> the description and you commit
single changelists, so this makes it easy 
>>>>>> to commit some files but not
others.
>>>>>> [snip asterisk]
>>>>>> 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.
>>> 
>>> 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. I'd say
let's stick 
with a manual 'edit' action, at least for perforce (maybe
aegis wants to 
do this differently). Anyway I think we are again drifting
into back end 
implementation and away from interface design.  I guess
maybe we 
should keep in mind that a VCS plugin may want to hook
certain events 
(maybe Kuba Ober could comment on this?).

>> 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". I'd be OK supporting that in the
VCS interface. In 
perforce there are also "labels" which are a
combination of a client and 
a revision number. So if you have /branches/3.5, you might
have labels 
"3.5.0", "3.5.1", "3.5.2",
etc, that correspond to a particular release. 
This might be "3.5.2 is /branches/3.5/... at revision
5127".

What I am thinking of as "branching" would be e.g.
creating 
/branches/4.0 containing the contents of /trunk.

>> 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...

Right... that's the idea. 

-- 
Matthew
<insert bad pun... on second thought, better not>


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 09.04.07 14:34:06, Matthew Woehlke wrote:
> dukju ahn wrote:
> > 2007/4/9, Andreas Pakulat <apakugmx.de>:
> >> On 09.04.07 10:53:43, Matthew Woehlke wrote:
> >>> Somehow "integrate" got left off
the list, that one is important.
> >> integrate? What was that again?
> > 
> > I guess that the integration he meant was creating
new project
> > by importing/checkout to/from remote repository.
> 
> No, "integrate" (at least in perforce
terminology) means to take changes 
> made to one file and apply them to another file
(usually one with a 
> common ancestor). It is literally 'make a patch, munge
the file names, 
> and apply it'. So for instances all those changes I've
been making to 
> KATE in branches/3.5 need to be "integrated"
and merged into trunk. 
> 
> integrate = Tell the VCS what you are doing (in some
VCS's this also 
> adds metadata about the integration so you can see that
such-and-such 
> version is the previous version plus integrations from
somewhere else, 
> possibly with edits on top of that also). If we have
branch, we need 
> integrate.
> 
> merge = Resolve conflicts, either from an update of
something you were 
> editing, or from an integration (i.e. merge !=
integrate; merge is a 
> 100% client-side operation). If we have update and diff
(of course we 
> do), we need merge.
> 
> Some VCS's may do the "merge" step implicitly
during an integrate or update.

In SVN terms your merge is a manual operation which needs to
be done
when there are conflicts. It is finalized be either svn
resolved or svn
revert. Changes that don't create a conflict (i.e. lines
that have not
been modified locally) are automatically integrated upon
doing svn up.

As for integrate: There's no exact match in svn, svn merge
comes close,
but thats merging 2 versions of a url into the working copy.
You can use
the diff between two "branches" of svn (i.e. 2
different urls, like
branches/3.5 and trunk) or you can use 2 revisions of the
file in the
same repository url (i.e. merge changes between 121423 and
342232 into
WC) or use differences between 2 other working copies.

> > IMHO the integration would go to basic interface
among the
> > separate interfaces.
> 
> It should go wherever 'branch' is IMO, since if you
can't branch, you 
> have nothing to integrate.

I agree. With svn I think the most used actions are
integrating the diff
between 2 revisions of a repository url or between 2
repository urls. So
it fits perfectly into the planned (by me of course)
ISourceCodeRepository. However I probably call it merge as
that fits
better with what it does, IMHO.

Andreas

-- 
Executive ability is prominent in your make-up.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel