From users-return-102-daniel=haxx.se@subversion.apache.org Mon Dec 21 15:06:02 2009 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id nBLE60l3021504 for ; Mon, 21 Dec 2009 15:06:01 +0100 Received: (qmail 73171 invoked by uid 500); 21 Dec 2009 14:05:54 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 73163 invoked by uid 99); 21 Dec 2009 14:05:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Dec 2009 14:05:53 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of guillaumebadin@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-yx0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Dec 2009 14:05:47 +0000 Received: by yxe10 with SMTP id 10so734724yxe.12 for ; Mon, 21 Dec 2009 06:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=I9X71DDAj7RBh2uzipTapwkmAeMosi69Ze4BY9Uxdrs=; b=xpg8+PcKjPRfZaqBDbVq9EnIqBIliUJHEXaDI/X4oBsDdBXC3iG40vgEV4N3EJllH2 sFHTj4c8N6ZbAcpWXklBrHQNJ4447TrVE0oX9GtGZPFOmnPBpa0GZ8yAg4aweiq1QfC7 yr8n202+zMRZLrOm0JrhRzRTnbA5Nq0+RS6Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VnQD06oDHoBvQgm1uMEcgg4LzvbXUZgg9/8Lo5Cf/rPBmmdZ40VuFyY2LN/T7hN0yC 9EiKme9XVWvnrO1O/kfR9lQeNvmvaqJNWXxFbAWPvHxdPmve7oDjG2ly/2FrFPKp45QW BiEULOtG072GNL2/uIFK60Hq+yAIlsMyZcZCw= MIME-Version: 1.0 Received: by 10.100.247.2 with SMTP id u2mr11329602anh.133.1261404311126; Mon, 21 Dec 2009 06:05:11 -0800 (PST) In-Reply-To: <9f9d73340912160016s4dfad14t76b3a261d9fed0e7@mail.gmail.com> References: <83ece3cd0912150833t2f61055dr6091f42a2182562b@mail.gmail.com> <9f9d73340912160016s4dfad14t76b3a261d9fed0e7@mail.gmail.com> From: Guillaume Date: Mon, 21 Dec 2009 15:04:51 +0100 Message-ID: <9f9d73340912210604u9ae5387pe22fa7a5eb6c9a38@mail.gmail.com> Subject: Re: Re : need have a begin transaction on different branch To: Bob Archer Cc: Thierry Robert , "users@subversion.apache.org" Content-Type: multipart/alternative; boundary=001636b431f0e2021c047b3d93b3 --001636b431f0e2021c047b3d93b3 Content-Type: text/plain; charset=UTF-8 up ? -- BADIN Guillaume Appartement 405 2 promenade des sapeurs pompiers 94800 Villejuif On Wed, Dec 16, 2009 at 9:16 AM, Guillaume wrote: > > My problem is not on ACID Transaction, my problem is that we have 3 > different projects. > These projects are dependent but are not in the same repository. > > ex : > 3 projects A, B, C > > If I made modifications on A and B : > - I commit A > - Other developer commit its own modification of B > - I cannot commit B (because of conflict) > - The build is broken until I resolved B conflicts > > My needs are If I made modifications on A and B : > - I lock A & B > - I commit A > - I commit B > - I unlock A & B > - Other developer commit its own modifications on project B > > > -- > BADIN Guillaume > Appartement 405 > 2 promenade des sapeurs pompiers > 94800 Villejuif > > > On Tue, Dec 15, 2009 at 6:38 PM, Bob Archer wrote: > >> > I have the same problem too. >> > I'm working in a company using subversion for its projects >> > I need to be able to lock folders on the repository before >> > committing them to avoid simultanous commits. >> > >> > -- >> > Thy >> >> subversion commits are ACID transactions so simultaneous commits will not >> cause any problems. >> >> If the file your are commiting isn't up to do svn will return an error. >> >> So, if you an I both submit a change to ^/foo.txt one of us will win the >> other will get an error that foo.txt is out of date and you need to update >> and commit again. When you update you will get either a clean merge or a >> conflict. If a conflict you resolve it and then you can commit again. >> > > >> So, you really don't need to be able to lock folders to avoid simultaneous >> commits. >> >> BOb >> > > > > > --001636b431f0e2021c047b3d93b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable up ?
--
BADIN Guillaume
Appartement 405
2 promena= de des sapeurs pompiers
94800 Villejuif


On Wed, Dec 16, 2009 at 9:16 AM, Guillau= me <guilla= umebadin@gmail.com> wrote:

My problem is not on ACID Transaction, my problem is that we have 3 dif= ferent projects.
These projects are dependent but are not in the same re= pository.

ex :
3 projects A, B, C

If I made modifications= on A and B :
=C2=A0- I commit A
=C2=A0- Other developer commit its own modification o= f B
=C2=A0- I cannot commit B (because of conflict)
=C2=A0- The build= is broken until I resolved B conflicts

My needs are If I made modif= ications on A and B :
=C2=A0- I lock A & B
=C2=A0- I commit A
=C2=A0- I commit B
=C2= =A0- I unlock A & B
=C2=A0- Other developer commit its own modificat= ions on project B


--
BADIN Guilla= ume
Appartement 405
2 promenade des sapeurs pompiers
94800 Villejuif


= On Tue, Dec 15, 2009 at 6:38 PM, Bob Archer <Bob.Archer@amsi.com&g= t; wrote:
> I have the same problem too.
> I'm working=C2=A0 in a company using subversion for its projects > I need to be able to lock folders on the repository before
> committing them to avoid simultanous commits.
>
> --
> Thy

subversion commits are ACID transactions so simultaneous commit= s will not cause any problems.

If the file your are commiting isn't up to do svn will return an error.=

So, if you an I both submit a change to ^/foo.txt one of us will win the ot= her will get an error that foo.txt is out of date and you need to update an= d commit again. When you update you will get either a clean merge or a conf= lict. If a conflict you resolve it and then you can commit again.
=C2=A0
So, you really don't need to be able to lock folders to avoid simultane= ous commits.

BOb





--001636b431f0e2021c047b3d93b3--