Skip Menu |

This queue is for tickets about the svk CPAN distribution.

Report information
The Basics
Id: 28494
Status: open
Priority: 0/
Queue: svk
People
Owner: Nobody in particular
Requestors: matt.fowles [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Jul 26 13:42:40 2007 matt.fowles [...] gmail.com - Ticket created
Subject: svk ci with conflicts can lead to mistakes
Consider the following scenario, a user makes local changes to a mirrored depot, the commit checks with the server and sees a conflict. The user is notified of the conflict and his commit message is saved in file svk-commitFOO (without any file list of what is to be committed). He then sync his depot and makes a few changes in other files to deal with the new commit. He then types `svk ci --file svk-commitFoo` intending to commit just the modified files he initially tried (and failed) to commit. Unfortunately, the result is that he accidentally commits everything modified in his local tree. I know that perforce avoids this mistake by moving changes from the default changeset to a numbered one upon commit attempt (even if it fails), so that the files involved will also be maintained. I think it would be nice if SVK did something similar.
  Thu Jul 26 18:06:25 2007 clkao [...] clkao.org - Correspondence added
Subject: Re: [rt.cpan.org #28494] svk ci with conflicts can lead to mistakes
Date: Fri, 27 Jul 2007 06:05:59 +0800
To: bug-svk [...] rt.cpan.org
From: "Chia-Liang Kao" <clkao [...] clkao.org>
Do you mean that --file is ignoring the original list of files to be committed? Show quoted text
> Consider the following scenario, a user makes local changes to a > mirrored depot, the commit checks with the server and sees a conflict. > The user is notified of the conflict and his commit message is saved in > file svk-commitFOO (without any file list of what is to be committed). > He then sync his depot and makes a few changes in other files to deal > with the new commit. He then types `svk ci --file svk-commitFoo` > intending to commit just the modified files he initially tried (and > failed) to commit. Unfortunately, the result is that he accidentally > commits everything modified in his local tree. > > I know that perforce avoids this mistake by moving changes from the > default changeset to a numbered one upon commit attempt (even if it > fails), so that the files involved will also be maintained. I think it > would be nice if SVK did something similar. >
  Thu Jul 26 18:06:29 2007 The RT System itself - Status changed from 'new' to 'open'
  Thu Jul 26 19:52:37 2007 matt.fowles [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #28494] svk ci with conflicts can lead to mistakes
Date: Thu, 26 Jul 2007 19:52:19 -0400
To: bug-svk [...] rt.cpan.org
From: "Matt Fowles" <matt.fowles [...] gmail.com>
clkao~ When I first ran the commit, I did not specify any files in particular, but there were 4 locally changed files. After updating and resolving conflicts, I changes several more files. The I ran `svk ci --file svk-commitFOO` which committed all the files I had changed locally, not just the original 4 in the commit that had been stopped earlier. I expected it to just commit the 4 from before and leave the others edited in my working copy (which is what perforce does). Matt On 7/26/07, clkao@clkao.org via RT <bug-svk@rt.cpan.org> wrote: Show quoted text
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=28494 > > > Do you mean that --file is ignoring the original list of files to be committed? >
> > Consider the following scenario, a user makes local changes to a > > mirrored depot, the commit checks with the server and sees a conflict. > > The user is notified of the conflict and his commit message is saved in > > file svk-commitFOO (without any file list of what is to be committed). > > He then sync his depot and makes a few changes in other files to deal > > with the new commit. He then types `svk ci --file svk-commitFoo` > > intending to commit just the modified files he initially tried (and > > failed) to commit. Unfortunately, the result is that he accidentally > > commits everything modified in his local tree. > > > > I know that perforce avoids this mistake by moving changes from the > > default changeset to a numbered one upon commit attempt (even if it > > fails), so that the files involved will also be maintained. I think it > > would be nice if SVK did something similar. > >
> >