[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 05.04.07 16:00:49, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > 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 :)
> 
> Eh, perforce is easy. :-) It's almost exactly like svn except you have 
> to 'p4 edit' before you can edit. And you have clients to map files from 
> the repo to your workspace instead of what amounts to a symlink to the 
> repo (i.e. you get exactly the entire tree, no more no less),

Symlink to the repository?? Which VCS does that stupidity?

> but that doesn't really change the workflow, just makes it easier
> (possibly? ;-)) to be selective about what you pull down.

Well, thats something svn does allow too, although if you're not
watching your fingers you easily checkout the whole of a project.

> aegis I don't get, from what I read it sounds like the files are on your 
> *drive* in strange places,

Right, the whole filesystem is your repository. It seems you have a base
folder "somewhere" and then you create a changeset somewhere else with
just the files you want to change. No idea how merging back or such
things work..

> and there was something about all sorts of 
> weird stuff you have to do with symlinks and... I admit I didn't read it 
> *real* closely but it sounded really strange. :-)

No, the symlinks are there to be able to compile inside a changeset, as
there are only few files in there not the whole project. But normal
buildsystems like qmake/cmake/make/whatever need the whole project.

> >>> 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...
> 
> We really need it in KTextEditor though, don't we? I'm happy to ask if 
> you think it's worthwhile.

Well it can't hurt...

> Or is KDevelop4 dropping KTextEditor support?

No, at least not as long as kate-devs still call it KTextEditor ;)

> >> 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". 
> 
> Yes, that sounds like perforce's "labels". I'm unconvinced of the 
> importance of trying to support that directly in KDevelop (I'm not 
> arguing against it, really, I'm just unconvinced).

Well, we'll leave it to the vcs plugins anyway, so they can decide...

> > 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.
> 
> ...and it's just "principle" that /tags/... is read only? I.e. it's 
> semantically special, but otherwise it's just another spot in the repo, 
> yes? If I am understanding you, this is just a "branch" with a "special" 
> target.

Right, in SVN everything is just a dir, the same is true for trunk and
branches. Actuall in KDE's svn repo the structure is 

/trunk
/branches
/tags

and then have trunk/projectA, trunk/projectB and so on. You can as well
do something like

/devel
/stable
/releases

or you can just drop all that and only have

/project

> Would svn have separate interfaces for "branch" and "tag", even though 
> they do the same thing under the covers? Other VCS back ends would need 
> them to be separate.

Uhm, SVN doesn't have an interface at all for branch or tag. You handle
a SVN repository just like a normal filesystem. So you literally copy a
branch at a specific revision to a tag:

svn copy https://svn.kde.org/home/kde/branches/KDE/3.5@623434
https://svn.kde.org/home/kde/tags/KDE/3.5.7

Thats all (behind the scenes this is not a real full copy, but thats
just details). 

Anyway, as I said above, both branching and tagging should be left to
the vcs plugin. I don't see the need for this to be in the common VCS
interface.

Andreas

-- 
You will get what you deserve.