You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> on 2003/08/18 14:17:28 UTC
RE: Disabling automatic conflict resolution?
One of my users asked me the same thing. She said, "What if, when I update,
a file I've been working on is merged with some lines from someone else, and
even though there are no conflicts, this breaks the code?"
I answered, "After you update, build and run it to make sure it's working."
She replied, "Yeah, but my working copy is now lost, as it was replaced with
the merged version. So now I have to manually go through the file and try to
sort out my code from the other code. I think I'll make a backup of my
working copy before I update each time."
Perhaps a useful feature would be a --paranoid switch to the "svn up"
command. This would treat merges like conflicts, I suppose...?
--- Eric
> Is there a way to disable automatic conflict resolution [meaning 'merge'
--- EW], so that all
> conflicts require manual intervention?
>
> I am looking into revision control systems for a company, and they
> would rather never have Subversion resolve any conflict but that have
> the user do this.
>
> If there's no option for this, is there a place in the source code
> where I can easily force all attempts at automatic conflict resolution
> to fail?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by ja...@jrv.org.
These points are exactly what I'm selling to, except that also the
committers are geographically dispersed across several continents,
meaning that races between clients are a real consideration.
In the enterprise scenario it's important to be able to bound the
worst-case scenario. The emphasis isn't on guaranteeing that Bad Things
never happen but rather on guaranteeing that no matter how bad things
get there is a recovery plan of known cost in time & effort.
For example I plan to look into having a server-side hook save a full
plain-text copy of every file that is changed. The point is not that
anyone thinks this is needed but rather that by doing this I need not
worry about a number of unlikely scenarios.
PS. The other big difference between open-source and enterprise
environments is the need to support lame users. The larger an
enterprise gets the more people you have inhabiting the wrong side
of the Bell Curve. Such people aren't attracted to open-source in
the first place or quickly go away, but in the enterprise they
form a sizeable population and may be impossible to get rid of.
> Date: Mon, 18 Aug 2003 10:00:03 -0700
> From: Jack Repenning <jr...@collab.net>
>
> Oh, yes, this is a real use case. It's more an enterprise thing than
> an open-source one, I suppose, so perhaps it's outside the "better
> CVS" touch-stone for SVN 1.0. The combination of things that drive
> some enterprise communities into this level of care are:
>
> * many many committers (hundreds, occasionally thousands) all with
> commit rights to the same files (or to all files)
>
> * diverse change mix (patches, maintenance, new development)
>
> * pervasive changes (like ports to new platforms, changes in core
> data structures)
>
> * paying customers who won't stand for disruption
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by ja...@jrv.org.
These points are exactly what I'm selling to, except that also the
committers are geographically dispersed across several continents,
meaning that races between clients are a real consideration.
In the enterprise scenario it's important to be able to bound the
worst-case scenario. The emphasis isn't on guaranteeing that Bad Things
never happen but rather on guaranteeing that no matter how bad things
get there is a recovery plan of known cost in time & effort.
For example I plan to look into having a server-side hook save a full
plain-text copy of every file that is changed. The point is not that
anyone thinks this is needed but rather that by doing this I need not
worry about a number of unlikely scenarios.
PS. The other big difference between open-source and enterprise
environments is the need to support lame users. The larger an
enterprise gets the more people you have inhabiting the wrong side
of the Bell Curve. Such people aren't attracted to open-source in
the first place or quickly go away, but in the enterprise they
form a sizeable population and may be impossible to get rid of.
> Date: Mon, 18 Aug 2003 10:00:03 -0700
> From: Jack Repenning <jr...@collab.net>
>
> Oh, yes, this is a real use case. It's more an enterprise thing than
> an open-source one, I suppose, so perhaps it's outside the "better
> CVS" touch-stone for SVN 1.0. The combination of things that drive
> some enterprise communities into this level of care are:
>
> * many many committers (hundreds, occasionally thousands) all with
> commit rights to the same files (or to all files)
>
> * diverse change mix (patches, maintenance, new development)
>
> * pervasive changes (like ports to new platforms, changes in core
> data structures)
>
> * paying customers who won't stand for disruption
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by Jack Repenning <jr...@collab.net>.
At 9:43 AM -0500 8/18/03, kfogel@collab.net wrote:
>If your user has had a different experience, that's one thing. But if
>she's just *anticipating* a problem, then I want to say "Try it and
>you'll see."
Oh, yes, this is a real use case. It's more an enterprise thing than
an open-source one, I suppose, so perhaps it's outside the "better
CVS" touch-stone for SVN 1.0. The combination of things that drive
some enterprise communities into this level of care are:
* many many committers (hundreds, occasionally thousands) all with
commit rights to the same files (or to all files)
* diverse change mix (patches, maintenance, new development)
* pervasive changes (like ports to new platforms, changes in core
data structures)
* paying customers who won't stand for disruption
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by Ben Collins-Sussman <su...@collab.net>.
Brandon Ehle <az...@yahoo.com> writes:
> >I'm not sure this is a big enough problem to warrant any special
> >support. Honestly, in ~8 years of working with copy-modify-merge
> >revision control systems (CVS and then Subversion), I think I've maybe
> >lost a total of 30 minutes to this sort of semantic problem. Usually
> >I knew in advance (from commit mails or other forms of developer
> >communication) that the incoming change was dangerous, and adjusted my
> >update accordingly.
> >
> >
> I'm not sure because I have never tried to do this with Subversion,
> but is it possible to switch to an older version of the file and have
> Subversion automatically unmerge changes from the repository or do you
> have to rely on diff and patch for this?
Of course, that's what backdating is all about.
Suppose you have rev 10 of a file, and you add local changeset "A".
Then you update to rev 15, which adds changeset "B".
Now your working file is basically 'r15 + A', or equivalently, 'r10 +
B + A'.
If you backdate your file ('svn up -r10'), changeset B is removed, and
you're back at 'r10 + A' again.
The issue here is: what if A and B overlap a tiny bit? In that
scenario, when you update to r15, you now have "r15 + *most* of A",
because of the merge. And your backdating will only leave you with
'r10 + *most* of A', because svn forgets the fact that the tiny
merge-overlap happened; it reverts all of change B when you backdate.
This is the scenario that Eric was talking about, and which cmpilato
and kfogel address.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by cm...@collab.net.
Brandon Ehle <az...@yahoo.com> writes:
> I'm not sure because I have never tried to do this with Subversion,
> but is it possible to switch to an older version of the file and have
> Subversion automatically unmerge changes from the repository or do you
> have to rely on diff and patch for this?
You can run 'svn up -r REV', where REV is some revision before the
changes, but that won't do quite what you think. By the time the
local mods and the exactly matching repos mods have been merged
together, the net effect is that there are no local mods in those
lines of code. To backup to a previous revision will rollback to the
old version, plus the user's remaining mods, but the fact that she
changed some lines that were also changed by someone else is already
lost.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by Brandon Ehle <az...@yahoo.com>.
kfogel@collab.net wrote:
>"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
>
>
>>One of my users asked me the same thing. She said, "What if, when I update,
>>a file I've been working on is merged with some lines from someone else, and
>>even though there are no conflicts, this breaks the code?"
>>
>>I answered, "After you update, build and run it to make sure it's working."
>>
>>She replied, "Yeah, but my working copy is now lost, as it was replaced with
>>the merged version. So now I have to manually go through the file and try to
>>sort out my code from the other code. I think I'll make a backup of my
>>working copy before I update each time."
>>
>>
>
>I'm not sure this is a big enough problem to warrant any special
>support. Honestly, in ~8 years of working with copy-modify-merge
>revision control systems (CVS and then Subversion), I think I've maybe
>lost a total of 30 minutes to this sort of semantic problem. Usually
>I knew in advance (from commit mails or other forms of developer
>communication) that the incoming change was dangerous, and adjusted my
>update accordingly.
>
>
>
I'm not sure because I have never tried to do this with Subversion, but
is it possible to switch to an older version of the file and have
Subversion automatically unmerge changes from the repository or do you
have to rely on diff and patch for this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by Jack Repenning <jr...@collab.net>.
At 9:43 AM -0500 8/18/03, kfogel@collab.net wrote:
>If your user has had a different experience, that's one thing. But if
>she's just *anticipating* a problem, then I want to say "Try it and
>you'll see."
Oh, yes, this is a real use case. It's more an enterprise thing than
an open-source one, I suppose, so perhaps it's outside the "better
CVS" touch-stone for SVN 1.0. The combination of things that drive
some enterprise communities into this level of care are:
* many many committers (hundreds, occasionally thousands) all with
commit rights to the same files (or to all files)
* diverse change mix (patches, maintenance, new development)
* pervasive changes (like ports to new platforms, changes in core
data structures)
* paying customers who won't stand for disruption
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by kf...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> One of my users asked me the same thing. She said, "What if, when I update,
> a file I've been working on is merged with some lines from someone else, and
> even though there are no conflicts, this breaks the code?"
>
> I answered, "After you update, build and run it to make sure it's working."
>
> She replied, "Yeah, but my working copy is now lost, as it was replaced with
> the merged version. So now I have to manually go through the file and try to
> sort out my code from the other code. I think I'll make a backup of my
> working copy before I update each time."
I'm not sure this is a big enough problem to warrant any special
support. Honestly, in ~8 years of working with copy-modify-merge
revision control systems (CVS and then Subversion), I think I've maybe
lost a total of 30 minutes to this sort of semantic problem. Usually
I knew in advance (from commit mails or other forms of developer
communication) that the incoming change was dangerous, and adjusted my
update accordingly.
If your user has had a different experience, that's one thing. But if
she's just *anticipating* a problem, then I want to say "Try it and
you'll see."
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Aug 18, 2003 at 07:17:28AM -0700, Wadsworth, Eric (Contractor) wrote:
>
> Perhaps a useful feature would be a --paranoid switch to the "svn up"
> command. This would treat merges like conflicts, I suppose...?
Something like "p4 resolve -v", which should
"Include conflict markers in the file for all changes between yours
and base, and between theirs and base. Normally, conflict markers
are included only when yours and theirs conflict."
(perforce manual)
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by cm...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> She replied, "Yeah, but my working copy is now lost, as it was replaced with
> the merged version. So now I have to manually go through the file and try to
> sort out my code from the other code. I think I'll make a backup of my
> working copy before I update each time."
Her changes are only "lost" if they were exactly the same as changes
someone else made. 'svn diff' will still show the changes she made
that weren't identically made as well by someone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by cm...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> She replied, "Yeah, but my working copy is now lost, as it was replaced with
> the merged version. So now I have to manually go through the file and try to
> sort out my code from the other code. I think I'll make a backup of my
> working copy before I update each time."
Her changes are only "lost" if they were exactly the same as changes
someone else made. 'svn diff' will still show the changes she made
that weren't identically made as well by someone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Aug 18, 2003 at 07:17:28AM -0700, Wadsworth, Eric (Contractor) wrote:
>
> Perhaps a useful feature would be a --paranoid switch to the "svn up"
> command. This would treat merges like conflicts, I suppose...?
Something like "p4 resolve -v", which should
"Include conflict markers in the file for all changes between yours
and base, and between theirs and base. Normally, conflict markers
are included only when yours and theirs conflict."
(perforce manual)
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Disabling automatic conflict resolution?
Posted by kf...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> One of my users asked me the same thing. She said, "What if, when I update,
> a file I've been working on is merged with some lines from someone else, and
> even though there are no conflicts, this breaks the code?"
>
> I answered, "After you update, build and run it to make sure it's working."
>
> She replied, "Yeah, but my working copy is now lost, as it was replaced with
> the merged version. So now I have to manually go through the file and try to
> sort out my code from the other code. I think I'll make a backup of my
> working copy before I update each time."
I'm not sure this is a big enough problem to warrant any special
support. Honestly, in ~8 years of working with copy-modify-merge
revision control systems (CVS and then Subversion), I think I've maybe
lost a total of 30 minutes to this sort of semantic problem. Usually
I knew in advance (from commit mails or other forms of developer
communication) that the incoming change was dangerous, and adjusted my
update accordingly.
If your user has had a different experience, that's one thing. But if
she's just *anticipating* a problem, then I want to say "Try it and
you'll see."
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org