You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/03/21 18:13:42 UTC
Re: Missing error messages with svn_error_quick_wrap [was: Re: "
Inconsistent line-endings"]
On Sat, 2004-03-20 at 11:04, Julian Foad wrote:
> "svn_error_quick_wrap" creates a wrapper error with the same error
> code as the wrapped error. If the wrapped error doesn't have an
> explicit message, "svn_handle_error" then doesn't print it at all
> (apart from the file and line debugging info).
> I think the best solution is for "svn_error_quick_wrap" to use the
> error code SVN_ERR_BASE rather than copy the wrapped error code. The
> default text for SVN_ERR_BASE is "A problem occurred; see later errors
> for details", which is exactly what "svn_error_quick_wrap" is for.
Hm, that doesn't seem right. The wrapped error should be recognizable
programmatically as the same kind of error as the one being wrapped.
I think the svn_handle_error behavior for this case is probably historic
and unjustified; it would be better to change the handling behavior than
the wrapping behavior.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Missing error messages with svn_error_quick_wrap [was: Re: "
Inconsistent line-endings"]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-03-21 at 18:44, Julian Foad wrote:
> It is recognizable programmatically: the error code "SVN_ERR_BASE"
> means "This is a wrapper; see the inner error for details including
> the specific error code." Is there a problem with that?
Yes. Compare:
if (err->apr_err == SVN_ERR_BLAH)
to:
for (rerr = err; rerr->apr_err == SVN_ERR_BASE; rerr = rerr->child)
;
if (rerr->apr_err == SVN_ERR_BLAH)
> > I think the svn_handle_error behavior for this case is probably historic
> > and unjustified; it would be better to change the handling behavior than
> > the wrapping behavior.
>
> I thought about ways to change that and could not find a satisfactory way. Can you?
Maybe just punt the print_strerror parameter to print_error, and always
print a message (either the APR one or the more specific one if
provided). It's hard to imagine why there would ever be an exact
duplicate of an error in the call chain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Missing error messages with svn_error_quick_wrap [was: Re: "
Inconsistent line-endings"]
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Sat, 2004-03-20 at 11:04, Julian Foad wrote:
>
>>"svn_error_quick_wrap" creates a wrapper error with the same error
>>code as the wrapped error. If the wrapped error doesn't have an
>>explicit message, "svn_handle_error" then doesn't print it at all
>>(apart from the file and line debugging info).
>
>>I think the best solution is for "svn_error_quick_wrap" to use the
>>error code SVN_ERR_BASE rather than copy the wrapped error code. The
>>default text for SVN_ERR_BASE is "A problem occurred; see later errors
>>for details", which is exactly what "svn_error_quick_wrap" is for.
>
> Hm, that doesn't seem right. The wrapped error should be recognizable
> programmatically as the same kind of error as the one being wrapped.
It is recognizable programmatically: the error code "SVN_ERR_BASE" means "This is a wrapper; see the inner error for details including the specific error code." Is there a problem with that?
> I think the svn_handle_error behavior for this case is probably historic
> and unjustified; it would be better to change the handling behavior than
> the wrapping behavior.
I thought about ways to change that and could not find a satisfactory way. Can you?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Folker Schamel <sc...@spinor.com>.
Ben Gollmer wrote:
> On Tue, 6 Apr 2004 05:45:48 -0500, Folker Schamel <sc...@spinor.com> wrote:
>
>>>But how would you ever get those 'plus modifications', if every change
>>>you made to either file was automatically merged to the other?
>>
>>To avoid misunderstandings:
>>I'm only taling about renames / copies *within* a project, e.g.
>>*within* trunk. I'm not talking about branch / tag copies.
>
>
>>From Subversion's point of view, there is _no difference_ between a trunk copy and a branch or tag
> copy.
I know very well
-> see my sample.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Ben Gollmer <be...@jatosoft.com>.
On Tue, 6 Apr 2004 05:45:48 -0500, Folker Schamel <sc...@spinor.com> wrote:
>> But how would you ever get those 'plus modifications', if every change
>> you made to either file was automatically merged to the other?
>
> To avoid misunderstandings:
> I'm only taling about renames / copies *within* a project, e.g.
> *within* trunk. I'm not talking about branch / tag copies.
Re: The "follow copy history" initiative
Posted by John Peacock <jp...@rowman.com>.
Folker Schamel wrote:
> To avoid misunderstandings:
> I'm only taling about renames / copies *within* a project, e.g.
> *within* trunk. I'm not talking about branch / tag copies.
As Ben already pointed out, there are no distinctions between copies, no matter
where they are. Copies are copies are copies. What you /mean/ by a particular
copy within your repository is unknowable by Subversion (or any tool for that
matter). You are responsible for developing your own work methods which may
lend significance to "copy within trunk" vs "copy to branch" but the tool cannot
do that for you.
>
> My point is: The need for a merge is independent
> from the file still having the same name,
> being renamed or being copied within a project.
This feature you are asking about (splitting sourcefiles and automatic merging
of bugfixes) is not within the scope of Subversion. You as the developer must
merge code changes like that; unless a SCM tool had a copy-history at the line
level, there is little or nothing that _any_ tool could do for you. AFAICT,
your request has nothing to do with the larger issue of "follow copy history" as
it exists in Subversion.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Folker Schamel <sc...@spinor.com>.
> On Mon, 5 Apr 2004 20:39:37 -0500, Folker Schamel <sc...@spinor.com> wrote:
>
>>It's not only "one scenario", its the standard case:
>>If a file has the history of another file,
>>this means per definition that it has the same content
>>plus modifications, and merging is necessary
>>in the same way as for normal modified files.
>
>
> But how would you ever get those 'plus modifications', if every change
> you made to either file was automatically merged to the other?
To avoid misunderstandings:
I'm only taling about renames / copies *within* a project, e.g.
*within* trunk. I'm not talking about branch / tag copies.
Of course, you don't want to propagate changes into a branch copy.
But when you merge, your branch is out of the merge scope anyway.
Sample:
You have
-> trunk/menu.c
-> trunk/dialog.c
you make a branch "copy trunk branch/1"
-> branches/1/menu.c
-> branches/1/dialog.c
and you make a second branch "copy branch/1 branch/2"
-> branches/2/menu.c
-> branches/2/dialog.c
In trunk, you split your dialog into two dialogs,
e.g. "copy trunk/dialog.c trunk/dialog1.c"
plus "move trunk/dialog.c trunk/dialog2.c"
and then modificating trunk/menu.c, trunk/dialog1.c,
and trunk/dialog2.c
-> trunk/menu.c
-> trunk/dialog1.c
-> trunk/dialog2.c
Then you do a bug fix A in branches/1/menu.c
and a bugfix B in branches/1/dialog.c.
This means that trunk/menu.c likely will contain bug A, too,
and trunk/dialog1.c and trunk/dialog2.c likely will contain
bug B, too, for the same reason. But of course
depending on the changes you did on the files.
Then, when merging "merge branches/1 -r m:n trunk"
you want to merge bug fix A into trunk/menu.c,
and bug fix B into trunk/dialog1.c and trunk/dialog2.c
NOT merging bug fix B into trunk/dialog1.c would be dangerous.
But of course, when merging from branches/1 to trunk,
you don't want to apply any changes to branches/2.
And of course, maybe because of changes in trunk/menu.c,
the bug fix A may make no sense to merge into trunk/menu.c
anymore, or in the same way because of changes in
trunk/dialog1.c, bug fix B may make no sense to merge into
trunk/dialog1.c anymore.
But thats a classical issue which is the same for menu.c and
dialog1.c and is no related to moving or copying in any way.
My point is: The need for a merge is independent
from the file still having the same name,
being renamed or being copied within a project.
Note that I am not talking about possible
implementations. As Greg I'm only talking about
"the best merge we can expect from a version control tool".
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Ben Gollmer <be...@jatosoft.com>.
On Mon, 5 Apr 2004 20:39:37 -0500, Folker Schamel <sc...@spinor.com> wrote:
> It's not only "one scenario", its the standard case:
> If a file has the history of another file,
> this means per definition that it has the same content
> plus modifications, and merging is necessary
> in the same way as for normal modified files.
But how would you ever get those 'plus modifications', if every change you made to either file was
automatically merged to the other?
It sounds like you are describing symlinks, not file copies.
--
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by John Peacock <jp...@rowman.com>.
Folker Schamel wrote:
> It's not only "one scenario", its the standard case:
> If a file has the history of another file,
> this means per definition that it has the same content
> plus modifications, and merging is necessary
> in the same way as for normal modified files.
I disagree almost completely. A copy with history, in the sense that Subversion
understands it, is a bifurcation. Two files can share the same ancestor, but
there is nothing in the system that requires that they continue to share the
same content. In fact, that would be a disaster for many situations.
For example, I branch my mainline to provide a bug fix, so I make a copy of a
file. Once I am happy with that branch, I release the bug fix, but then decide
not to make that same change to the trunk and fix it another way. There is no
way for the tool to know which way to merge these two changes, and in fact it
would be outright wrong to automate any merge.
> But if the content of the copied file is fundametally different
> from its original, it makes no sense to talk about / keep the history,
> and it should be treated as new file.
But it is _not_ a new file; it shares a common ancestor with the other file.
This is a good thing, since the common parts of both files share the same
development path (so I can do a blame analysis on either file to see when a
given common line was added).
>
> If you say that because of implementation issues
> this is too complicated, then the right solution is
> to support moves, but no copies at all.
> Copy with history but without merge support makes no sense.
There are no moves in Subversion; only copies and deletes.
The normal copy in Subversion copies only the pointer to the original file (and
it's history). If I then change the copy, Subversion actually copies the file
and creates a new node (with the same history as the previous), so that the two
files are no longer sharing the same node, but have diverged.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Folker Schamel <sc...@spinor.com>.
> Propagating a merged change to all copies of a file would be a distinct
> case of the version control tool being too clever. If foo has been
> copied to bar in order to create a branch of foo, then it's up to the
> user to propagate the bugfix or not depending on the nature of the
> branch. If foo has been copied to bar in order to create a different
> but derived implementation (e.g. ra_svn's editor.c being copied to
> editorp.c), then a change to the original may or may not make sense for
> the copy.
As for every normal modified file in the branch, too:
A merge may or may not make sense.
> Just because you can imagine one scenario where it's a good idea to do
> something clever and complicated doesn't mean it's a good idea to
> implement the clever and complicated feature.
It's not only "one scenario", its the standard case:
If a file has the history of another file,
this means per definition that it has the same content
plus modifications, and merging is necessary
in the same way as for normal modified files.
(But of course, in a particular case a merge may be not
senseful or may fail in both cases if you have overlapping
non-orthogonal changes).
But if the content of the copied file is fundametally different
from its original, it makes no sense to talk about / keep the history,
and it should be treated as new file.
If you say that because of implementation issues
this is too complicated, then the right solution is
to support moves, but no copies at all.
Copy with history but without merge support makes no sense.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The "follow copy history" initiative
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-04-05 at 06:43, Folker Schamel wrote:
> > BASELINE: contains file "foo"
> > MAINLINE: copies "foo" to "bar"; renames "foo" to "baz"
> > BRANCH: modifies file "foo"
> >
> > The best merge result we can expect from a version control tool has the
> > branch's modifications to "foo" merged into "baz", with "bar"
> > unchanged. To get this result, we have to distinguish the rename from
> > the copy.
> >
>
> I think this is not correct.
>
> Suppose for example the modification of "foo" in BRANCH
> are a bug fix, then the bug should (must?) be fixed BOTH
> in "bar" and "baz".
> Because - except in case of an overlapping modification -
> both files contain the bug.
Propagating a merged change to all copies of a file would be a distinct
case of the version control tool being too clever. If foo has been
copied to bar in order to create a branch of foo, then it's up to the
user to propagate the bugfix or not depending on the nature of the
branch. If foo has been copied to bar in order to create a different
but derived implementation (e.g. ra_svn's editor.c being copied to
editorp.c), then a change to the original may or may not make sense for
the copy.
Just because you can imagine one scenario where it's a good idea to do
something clever and complicated doesn't mean it's a good idea to
implement the clever and complicated feature.
> If "bar" would be fundamentally different from "foo",
> so that bug fixes of "foo" are never relevant for "bar",
> then "bar" should be added as new file and not as copy of "foo".
The fundamental reason to copy a file rather than create a new one is to
preserve history, not to create some kind of Byzantine automated change
propagation network.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
The "follow copy history" initiative
Posted by Folker Schamel <sc...@spinor.com>.
From: Greg Hudson <gh...@MIT.EDU>:
> Imagine for a moment that we had really good merge support. Say I want
> to perform the following merge:
>
> BASELINE: contains file "foo"
> MAINLINE: copies "foo" to "bar"; renames "foo" to "baz"
> BRANCH: modifies file "foo"
>
> The best merge result we can expect from a version control tool has the
> branch's modifications to "foo" merged into "baz", with "bar"
> unchanged. To get this result, we have to distinguish the rename from
> the copy.
>
I think this is not correct.
Suppose for example the modification of "foo" in BRANCH
are a bug fix, then the bug should (must?) be fixed BOTH
in "bar" and "baz".
Because - except in case of an overlapping modification -
both files contain the bug.
If "bar" would be fundamentally different from "foo",
so that bug fixes of "foo" are never relevant for "bar",
then "bar" should be added as new file and not as copy of "foo".
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org