You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by lightbulb432 <ve...@hotmail.com> on 2007/02/14 16:46:39 UTC
Update before commit
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?
Does this depend on whether somebody has made a change to *anything* in the
repository (hence increasing the revision number of the project), or whether
they've made a change to the files you've changed in your repository?
I ask because I read an article about continuous integration that says the
build on the integration server might fail if you forget to update before
checking in...that sounds scary and like there's no failure from Subversion
when something like this happens (isn't that the kind of thing that version
control prevents)?
--
View this message in context: http://www.nabble.com/Update-before-commit-tf3228333.html#a8968765
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
Re: [RFE] Update before commit
Posted by Andy Levy <an...@gmail.com>.
On 2/14/07, lightbulb432 <ve...@hotmail.com> wrote:
>
> 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?)
Subversion has no concept of inter-file dependencies. Sounds more like
the responsibility of a build system or development environment, not a
version control system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: Update before commit
Posted by Dave Grundgeiger <da...@codenouveau.com>.
> 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?
This is why I love continuous integration. In this situation the automatic
build will fail, send an email to the team, and developer 2 will fix it or
talk to developer 1 as necessary.
Dave
Dave Grundgeiger
CodeNouveau, LLC
Develop .NET Software with Open-Source Tools
http://www.codenouveau.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Update before commit
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Thu, 15 Feb 2007 08:30:16 -0800 (PST), lightbulb432
<ve...@hotmail.com> wrote:
>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?
No. "svn update" will take you to the last committed version. "svn
commit" will then commit your changes. Yes, it is theoretically
possible someone could commit a change between your "update" and
"commit", but if other people are regularly making changes to the
files that you are also making changes too, then you've got bigger
problems than source code management.
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
Re: Update before commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 15, 2007, at 10:30, lightbulb432 wrote:
> 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 the files you are modifying have been modified by someone else
since the last time you updated, you will be told that your files are
out of date and you must update first before you can commit. However,
if changes have been made in the repository to other files that you
are not modifying in this commit, then your commit will be allowed to
proceed.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Update before commit
Posted by Ch...@qimonda.com.
Merge applies the deltas between the repository files and
your checked out files, to YOUR checked out files.
Commit applies the deltas between the repository files and
your checked out files, to the REPOSITORY files.
>-----Original Message-----
>From: lightbulb432 [mailto:veerukrishnan@hotmail.com]
>Sent: Thursday, February 15, 2007 11:30 AM
>To: users@subversion.tigris.org
>Subject: RE: Re: Update before commit
>
>
>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
>>>> <ve...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Update before commit
Posted by lightbulb432 <ve...@hotmail.com>.
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
>>> <ve...@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
Re: Update before commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 14, 2007, at 14:35, 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?
Yes, that's technically possible. If the changes are in different
files, then Subversion will happily let you commit the changes.
However, I cannot think of a way that doing so could break a project.
Well, maybe I could...
developers 1 and 2 get working copies.
file foo contains a function foo() that does something, and various
files in the project use foo().
developer 1 renames function foo() to bar() and updates the reference
in all files that used foo() so that they now use bar().
developer 2 writes a new file which uses foo().
Both developers commit. Now, what's in the repository doesn't work --
developer 2's code uses foo() which is not called that anymore.
But I would think this situation wouldn't occur that often. I would
think that developers should communicate with one another, via email
or meetings or similar, letting one another know what they're doing.
If developer 1 planned to rename the function, this should have been
a consensus among the developers. Or the other developers should at
least have been informed that a public function was about to change
names. And so forth.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Update before commit
Posted by lightbulb432 <ve...@hotmail.com>.
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
>> <ve...@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#a8972879
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
RE: Re: [RFE] Update before commit
Posted by "Norton, Richard" <Ri...@lfg.com>.
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
> <ve...@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
Re: [RFE] Update before commit
Posted by lightbulb432 <ve...@hotmail.com>.
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
> <ve...@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
Re: Update before commit
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Wed, 14 Feb 2007 08:46:39 -0800 (PST), lightbulb432
<ve...@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