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
Received on Thu Feb 15 22:00:45 2007