[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question about concurrent commits

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2001-01-18 00:51:49 CET

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

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.