Avi Bryant <avi at beta4.com> said:
>Yes, branching is needed.  What you're describing there is more or less
>how CVS does things - always merge on the client side, and explicitly
>branch the working copy when needed.  The other model I'm considering is
>how I'm told StORE does things - every commit is effectively a branch, and
>you can ask the server to merge any two whenever you want.  With that
>model, there's no merging on the client side - any update is
>effectively a checkout.
>
A problem with StORE is that you can branch without knowing (if you don't look
really careful at the proposed version numbers), this happens a lot with
multiple developers. When one finds out, some checkins later, you are faced
with a merge over quite a number of versions which StORE ain't very good at
(that's a problem with the StORE model, where the remote, central part is just
a SQL database and you therefore need to fetch all the stuff to your image in 
order to merge - that gets slow quickly).

I'd rather have the option to choose on check-in. Even then, a
commit-on-a-branch first with a subsequent merge would be fine. I do like the
philosophy of StORE that 'the trunk' is whatever branch you care to designate
as 'the trunk' and be liberal about branching. Branching in CVS is too hard.

>As for lighterweight protocols than XML-RPC - well, XML-RPC is pretty darn
>lightweight, but since you'll notice that there's only a small and well
>separated bit of code that deals with the remote repository access, feel
>free to send me an alternate implementation.  I'd be happy to lose some
>dependencies.
>
SRP?


-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo