You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com> on 2007/04/10 17:12:35 UTC
Code Loss!?
I just read this in the SVN Book:
"...suppose that while working on your private branch, you rename
integer.c to whole.c. Effectively you've created a new file in your
branch that is a copy of the original file, and deleted the original
file. Meanwhile, back on trunk, Sally has committed some improvements to
integer.c. Now you decide to merge your branch to the trunk. ...The
merge operation has deleted the latest version of integer.c file (the
one containing Sally's latest changes), and blindly added your new
whole.c file - which is a duplicate of the older version of integer.c.
The net effect is that merging your "rename" to the branch has removed
Sally's recent changes from the latest revision!"
Coming from CVS, I was happy to have rename and move functionality, but
now I'm not so sure.
I consider pretty serious: there is a known, predictable situation that
will result in code loss. I'd have to consider this a "defect" and not a
"feature". Does anyone know if this is being worked on? Thanks
Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Code Loss!?
Posted by Dmitri Colebatch <di...@colebatch.com>.
> > Thanks - can I ask one further question (we've only been
> > using Subversion for a few months, having come across from
> > CVS). My understanding is that Subversion has no distinction
> > between a file that has been copied, and a file that has been
> > renamed. In both cases the new file is simply a file that
> > has inherited history. Is this correct?
>
> I think you are correct. A rename in Subversion is implemented as a copy
> and a delete. The Subversion designers have recognized for some time
> that this was a design mistake.
That would be this issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=898 (sorry - I
should have looked first).
> > The reason I ask is that I think there is a difference. The
> > main one being the difference between creating a branch, and
> > renaming a file on that branch. I assume the lack of
> > distinction between these two activities is the reason why
> > this functionality is missing. Correct?
> >
> Sorry, I didn't really understand this paragraph.
Sorry. Internally, there's not much SVN can do on this front (as I
understand it) without knowing if a new file with history is a move,
copy, or "file split". I think this is better covered in the above
bug already - thanks for your help.
cheers,
dim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Code Loss!?
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
>
> On 4/16/07, Irvine, Chuck R [EQ] <Ch...@embarq.com> wrote:
> > > Is this something that might be covered/coverable in the merge
> > > tracking functionality?
> >
> > As far as been indicated on the mailing list, no this won't be
> > addressed in the merge tracking initiaitve. The most current
> > information is that fixing this problem will be considered for
> > inclusion in 1.6.
>
> Thanks - can I ask one further question (we've only been
> using Subversion for a few months, having come across from
> CVS). My understanding is that Subversion has no distinction
> between a file that has been copied, and a file that has been
> renamed. In both cases the new file is simply a file that
> has inherited history. Is this correct?
I think you are correct. A rename in Subversion is implemented as a copy
and a delete. The Subversion designers have recognized for some time
that this was a design mistake.
>
> The reason I ask is that I think there is a difference. The
> main one being the difference between creating a branch, and
> renaming a file on that branch. I assume the lack of
> distinction between these two activities is the reason why
> this functionality is missing. Correct?
>
Sorry, I didn't really understand this paragraph.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Code Loss!?
Posted by Dmitri Colebatch <di...@colebatch.com>.
Hi,
On 4/16/07, Irvine, Chuck R [EQ] <Ch...@embarq.com> wrote:
> > Is this something that might be covered/coverable in the
> > merge tracking functionality?
>
> As far as been indicated on the mailing list, no this won't be addressed
> in the merge tracking initiaitve. The most current information is that
> fixing this problem will be considered for inclusion in 1.6.
Thanks - can I ask one further question (we've only been using
Subversion for a few months, having come across from CVS). My
understanding is that Subversion has no distinction between a file
that has been copied, and a file that has been renamed. In both cases
the new file is simply a file that has inherited history. Is this
correct?
The reason I ask is that I think there is a difference. The main one
being the difference between creating a branch, and renaming a file on
that branch. I assume the lack of distinction between these two
activities is the reason why this functionality is missing. Correct?
cheers,
dim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Code Loss!?
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
[snip]
> >
> > Coming from CVS, I was happy to have rename and move functionality,
> > but now I'm not so sure.
> >
> > I consider pretty serious: there is a known, predictable situation
> > that will result in code loss. I'd have to consider this a "defect"
> > and not a "feature". Does anyone know if this is being worked on?
> > Thanks
>
> Is this something that might be covered/coverable in the
> merge tracking functionality?
>
As far as been indicated on the mailing list, no this won't be addressed
in the merge tracking initiaitve. The most current information is that
fixing this problem will be considered for inclusion in 1.6.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Code Loss!?
Posted by Dmitri Colebatch <di...@colebatch.com>.
On 4/11/07, Irvine, Chuck R [EQ] <Ch...@embarq.com> wrote:
[snip]
> The net effect is that merging your "rename" to the branch has removed
> Sally's recent changes from the latest revision!"
>
> Coming from CVS, I was happy to have rename and move functionality, but
> now I'm not so sure.
>
> I consider pretty serious: there is a known, predictable situation that
> will result in code loss. I'd have to consider this a "defect" and not a
> "feature". Does anyone know if this is being worked on? Thanks
Is this something that might be covered/coverable in the merge
tracking functionality?
cheers,
dim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Code Loss!?
Posted by Lieven Govaerts <sv...@mobsol.be>.
Irvine, Chuck R [EQ] wrote:
>>>
>>> I consider pretty serious: there is a known, predictable situation
>>> that will result in code loss. I'd have to consider this a "defect"
>>> and not a "feature". Does anyone know if this is being worked on?
>>>
FYI, this is considered an issue. It's reported as issue 2685 in the
Issue Tracker:
http://subversion.tigris.org/issues/show_bug.cgi?id=2685
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Code Loss!?
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, April 10, 2007 2:27 PM
> To: Irvine, Chuck R [EQ]
> Cc: users@subversion.tigris.org
> Subject: Re: Code Loss!?
>
>
> Irvine, Chuck R [EQ] wrote:
> > I just read this in the SVN Book:
> >
> > "...suppose that while working on your private branch, you rename
> > integer.c to whole.c. Effectively you've created a new
> file in your
> > branch that is a copy of the original file, and deleted the
> original
> > file. Meanwhile, back on trunk, Sally has committed some
> improvements
> > to integer.c. Now you decide to merge your branch to the
> trunk. ...The
> > merge operation has deleted the latest version of integer.c
> file (the
> > one containing Sally's latest changes), and blindly added your new
> > whole.c file - which is a duplicate of the older version of
> integer.c.
> > The net effect is that merging your "rename" to the branch
> has removed
> > Sally's recent changes from the latest revision!"
> >
> > Coming from CVS, I was happy to have rename and move functionality,
> > but now I'm not so sure.
> >
> > I consider pretty serious: there is a known, predictable situation
> > that will result in code loss. I'd have to consider this a "defect"
> > and not a "feature". Does anyone know if this is being worked on?
> > Thanks
>
> The code is only "lost" as in "you have to work to find it",
> not lost as
> in gone. If you want the stuff that was on the trunk before
> your merge
> back, check that revision back out - or diff against it to see what
> happened.
Well, you're right, it is retrievable, but the problem is you might
never know that the code got dropped until the problems surfaces,
perhaps as a defect in production. Then, after much pain, you isolate
the problem and resurrect the code.
It would be much better to get a conflict notification of some sort,
something like "rename of foo conflicts with change or foo".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Code Loss!?
Posted by Les Mikesell <le...@gmail.com>.
Irvine, Chuck R [EQ] wrote:
> I just read this in the SVN Book:
>
> "...suppose that while working on your private branch, you rename
> integer.c to whole.c. Effectively you've created a new file in your
> branch that is a copy of the original file, and deleted the original
> file. Meanwhile, back on trunk, Sally has committed some improvements to
> integer.c. Now you decide to merge your branch to the trunk. ...The
> merge operation has deleted the latest version of integer.c file (the
> one containing Sally's latest changes), and blindly added your new
> whole.c file - which is a duplicate of the older version of integer.c.
> The net effect is that merging your "rename" to the branch has removed
> Sally's recent changes from the latest revision!"
>
> Coming from CVS, I was happy to have rename and move functionality, but
> now I'm not so sure.
>
> I consider pretty serious: there is a known, predictable situation that
> will result in code loss. I'd have to consider this a "defect" and not a
> "feature". Does anyone know if this is being worked on? Thanks
The code is only "lost" as in "you have to work to find it", not lost as
in gone. If you want the stuff that was on the trunk before your merge
back, check that revision back out - or diff against it to see what
happened.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org