On Wed, Jan 17, 2001 at 08:55:09PM +0100, Branko Čibej wrote:
> Kevin Pilch-Bisson wrote:
>
> > Hi again,
> >
> > I have just been perusing the interfaces in subversion/include/ and some
> > of the desing docs, and I had a question about concurrent commits. What
> > happens when two people are doing commits at the same time and both have
> > modified the same file foo.c:17. Assuming one of them finishes first,
> > their transaction is committed, and foo becomes foo.c:18. Then when the
> > second person commits, their delta is against foo.c:17, but the latest
> > copy in the repository is foo.c:18. From the way I interpreted the
> > design docs, a situation like this will cause a branch in the repository
> > at foo.c:17.
> >
> > Am I correct? Or is there some other way that this type of situation is
> > handled?
>
> If there's a conflict, the second commit will fail. You'll have to
> update your working copy (merging any changes) and try again. There's
> not much else to do.
>
> Branching automagically like that would be weird, to say the least.
>
I definitely agree that it would be weird. It just seemed to me that
that would be the way subversion works from the design doc. I guess my
question was how does the server distinguish between a normal commit
like this, and a branch. Based on the design doc it seems as if they are
identical, unless the client takes care of distinguishing between the
two. Am I missing something from the design doc?
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:19 2006