You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> on 2003/08/18 14:58:04 UTC
svn up --paranoid [was "Disabling automatic conflict resolution"
]
> > 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.
Her lines of code were merged with what was in the repository. If she wants
to restore this file in her working copy to its state before the "svn up"
command was executed, she must manually go through the file, line-by-line,
and remove lines added by the merge process. The original file, premerged,
is lost (though all of the lines of code are preserved in the merged file,
they much be manually sorted out).
That's the issue this user has with subversion, and why she is making backup
copies of her working copy before doing "svn up".
After some thought, a --paranoid flag on "svn up" wouldn't have to produce a
conflict... all it would have to do is make a backup copy of the working
copy of any file that is merged. I think this solution would make her happy.
--- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up --paranoid [was "Disabling automatic conflict resolution" ]
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Karl:
This doesn't quite work because, as someone else mentioned (cmpilato I
think?) changes that were the same both locally and remotely are destroyed
during this process. The information content is lost as no one bothers to
record it. The way Subversion currently stands (unlike CVS, which is an
important note; see my e-mail on the other thread), you can't recover from a
merge process if it went horribly wrong.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: <kf...@collab.net>
To: "Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil>
Cc: <cm...@collab.net>; <ja...@jrv.org>;
<us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Monday, August 18, 2003 10:01 AM
Subject: Re: svn up --paranoid [was "Disabling automatic conflict
resolution" ]
...
> That's not true. Consider:
>
> $ svn up
> G foo.txt <-- oh no, repos changes merged into modified local copy
> $ svn diff foo.txt > my-adjusted-changes.txt
> $ svn up -r<EARLIER_REV> foo.txt
> G foo.txt
> $
...
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up --paranoid [was "Disabling automatic conflict resolution" ]
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Karl:
This doesn't quite work because, as someone else mentioned (cmpilato I
think?) changes that were the same both locally and remotely are destroyed
during this process. The information content is lost as no one bothers to
record it. The way Subversion currently stands (unlike CVS, which is an
important note; see my e-mail on the other thread), you can't recover from a
merge process if it went horribly wrong.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: <kf...@collab.net>
To: "Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil>
Cc: <cm...@collab.net>; <ja...@jrv.org>;
<us...@subversion.tigris.org>; <de...@subversion.tigris.org>
Sent: Monday, August 18, 2003 10:01 AM
Subject: Re: svn up --paranoid [was "Disabling automatic conflict
resolution" ]
...
> That's not true. Consider:
>
> $ svn up
> G foo.txt <-- oh no, repos changes merged into modified local copy
> $ svn diff foo.txt > my-adjusted-changes.txt
> $ svn up -r<EARLIER_REV> foo.txt
> G foo.txt
> $
...
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up --paranoid [was "Disabling automatic conflict resolution" ]
Posted by kf...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> Her lines of code were merged with what was in the repository. If she wants
> to restore this file in her working copy to its state before the "svn up"
> command was executed, she must manually go through the file, line-by-line,
> and remove lines added by the merge process. The original file, premerged,
> is lost (though all of the lines of code are preserved in the merged file,
> they much be manually sorted out).
That's not true. Consider:
$ svn up
G foo.txt <-- oh no, repos changes merged into modified local copy
$ svn diff foo.txt > my-adjusted-changes.txt
$ svn up -r<EARLIER_REV> foo.txt
G foo.txt
$
The local changes to foo.txt should be preserved. Even if I'm wrong
about that (I haven't bothered to test it), she could still do the
following at this point:
$ patch foo.txt < my-adjusted-changes.txt
So it's not hard to get back to the original modified state, if she
really needs to.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn up --paranoid [was "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.
>
> Her lines of code were merged with what was in the repository. If she wants
> to restore this file in her working copy to its state before the "svn up"
> command was executed, she must manually go through the file, line-by-line,
> and remove lines added by the merge process. The original file, premerged,
> is lost (though all of the lines of code are preserved in the merged file,
> they much be manually sorted out).
Okay, I can see this as being interesting from a theoretical point of
view. Now, what's the use-case? That is, why is it important that
she know which lines of code she changed were the same lines of code
that someone else changed in the same way? Had she run 'svn up'
before starting her change, she wouldn't have changed those lines at
all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up --paranoid [was "Disabling automatic conflict resolution" ]
Posted by kf...@collab.net.
"Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil> writes:
> Her lines of code were merged with what was in the repository. If she wants
> to restore this file in her working copy to its state before the "svn up"
> command was executed, she must manually go through the file, line-by-line,
> and remove lines added by the merge process. The original file, premerged,
> is lost (though all of the lines of code are preserved in the merged file,
> they much be manually sorted out).
That's not true. Consider:
$ svn up
G foo.txt <-- oh no, repos changes merged into modified local copy
$ svn diff foo.txt > my-adjusted-changes.txt
$ svn up -r<EARLIER_REV> foo.txt
G foo.txt
$
The local changes to foo.txt should be preserved. Even if I'm wrong
about that (I haven't bothered to test it), she could still do the
following at this point:
$ patch foo.txt < my-adjusted-changes.txt
So it's not hard to get back to the original modified state, if she
really needs to.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up --paranoid [was "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.
>
> Her lines of code were merged with what was in the repository. If she wants
> to restore this file in her working copy to its state before the "svn up"
> command was executed, she must manually go through the file, line-by-line,
> and remove lines added by the merge process. The original file, premerged,
> is lost (though all of the lines of code are preserved in the merged file,
> they much be manually sorted out).
Okay, I can see this as being interesting from a theoretical point of
view. Now, what's the use-case? That is, why is it important that
she know which lines of code she changed were the same lines of code
that someone else changed in the same way? Had she run 'svn up'
before starting her change, she wouldn't have changed those lines at
all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org