Oooh, I think I've been getting mixed up between the behavior of merge and
commit. With merge, I understand that non-conflicting and
conflicting-but-mergeable changes are merged without even asking the
developer.
But with commit, is that the same behavior (where if you do a commit but
somebody has made a non-conflicting or conflicting-but-mergeable change, it
STILL commits), or will it say "your working copy was based on revision 10,
the repository is now on revision 15...even though there are no conflicting
changes, you're gonna have to do an update before I let you commit even
though you've edited different files than revisions 11 through 15"?
If it's the latter case, that sounds like a good plan for protection, but in
huge projects with lots of developers and frequent commits, wouldn't you be
doing update after update after update just to try to get in that one
commit?
If I've misunderstood completely, I wouldn't be surprised :) Please clarify,
thanks.
lightbulb432 wrote:
>
> Could two developers who have just done an update to their working copy
> and are doing two different parts of the code (with a dependency to each
> other though) do a build/test cycle locally and determine their changes
> are good.
>
> Developer 1 commits his changes, then developer 2. Because developer 2
> didn't modify the same files that developer 1 did, this second commit goes
> through successfully. But because those files are dependent on each other,
> the repository doesn't build?
>
> Of course the odds of this happening aren't great, but is what I've
> described a possible scenario (or am I missing something)? How would you
> get around this or handle this when it happens?
>
> Thanks.
>
>
>
> Norton, Richard wrote:
>>
>> This is actually the point of the 'update, then commit' methodology.
>>
>> You update your working copy with anything else that might have changed
>> in the repository since you got your copy, and perform a final build/test
>> cycle in your working area before you commit your changes to the
>> repository. This should allow you to catch any broken dependency issues
>> before you commit your work.
>>
>> -----Original Message-----
>> From: lightbulb432 [mailto:veerukrishnan@hotmail.com]
>> Sent: Wednesday, February 14, 2007 11:00 AM
>> To: users@subversion.tigris.org
>> Subject: Re: [RFE] Update before commit
>>
>>
>>
>> So it's only refused when a change happens to a file that you've changed?
>> If
>> somebody changes a different file in the repository (but that still has
>> dependencies with the file you've changed), the code in the repository
>> could
>> still break, right, even though the commit is accepted?
>>
>> Any strategies for resolving such a case to ensure the repository
>> contains a
>> fully functioning code base, or is this a usual part of the development
>> process?
>>
>> (e.g. Any way of declaring a dependency of one file on another so that
>> you
>> can't commit a file without first resolving conflicts not only in that
>> file
>> itself, but in files you've declared that it depends on. If not, any
>> thoughts about this as a feature request?)
>>
>>
>>
>>
>> Greg Thomas wrote:
>>>
>>> On Wed, 14 Feb 2007 08:46:39 -0800 (PST), lightbulb432
>>> <veerukrishnan@hotmail.com> wrote:
>>>
>>>>Is an update before a commit necessary, or will Subversion tell you when
a
>>>>repository has been updated since you checked out your working copy and
>>>>REQUIRE an update?
>>>
>>> An update is not generally required. However, if someone has committed
>>> something you are about to commit since you last updated, Subversion
>>> will refuse to commit - you'll have to do an update, resolve any
>>> conflicts that may arise, and then commit again.
>>>
>>> Greg
>>> --
>>> This post represents the views of the author and does
>>> not necessarily accurately represent the views of BT.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Update-before-commit-tf3228333.html#a8968969
>> Sent from the Subversion Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>> Notice of Confidentiality: **This E-mail and any of its attachments may
>> contain Lincoln National Corporation proprietary information, which is
>> privileged, confidential, or subject to copyright belonging to the
>> Lincoln National Corporation family of companies. This E-mail is intended
>> solely for the use of the individual or entity to which it is addressed.
>> If you are not the intended recipient of this E-mail, you are hereby
>> notified that any dissemination, distribution, copying, or action taken
>> in relation to the contents of and attachments to this E-mail is strictly
>> prohibited and may be unlawful. If you have received this E-mail in
>> error, please notify the sender immediately and permanently delete the
>> original and any copy of this E-mail and any printout. Thank You.**
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Update-before-commit-tf3228333.html#a8988663
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 15 17:31:32 2007