> On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright
> wrote:
> > On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard
> wrote:
> >> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> wrote:
> >>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard
> wrote:
>
> Finally, in your new design do not
I am reticent to comment to the developer community directly (and you
can see it has only happened a couple of times in 10 years), but as
someone who's been focused for the life of Subversion on its
implementation for enterprises and has been the source of impetus for
much of what CollabNet has con
On Jul 12, 2011, at 12:34 PM, Daniel Shahaf wrote:
> Why can't you --- as Paul already said --- just enforce a policy "Don't
> do subtree merges"?
>
>> If newmerge is successful and we want people to
>> move to it, we can force the conversion by asking "svn" to read the
>> old merginfo and write
On Tue, Jul 12, 2011 at 1:12 PM, Julian Foad wrote:
> I see three main thrusts behind the whole proposal, that are each much
> more significant than any of the specific concrete ideas. The first is
> that it's time to try some experiments in merge tracking.
+1
> The second is
> that restricting
On Tue, Jul 12, 2011 at 1:05 PM, Andy Singleton wrote:
> Log and blame will not be problems. My proposal does not change log or
> blame. They will still work fine if you apply newmerge. The revisions and
> authors and commit messages are still in the repository in the same place,
> and log and
I see three main thrusts behind the whole proposal, that are each much
more significant than any of the specific concrete ideas. The first is
that it's time to try some experiments in merge tracking. The second is
that restricting merges (primarily to the scope of "a whole branch") is
key to redu
On Tue, Jul 12, 2011 at 11:55 AM, Andy Singleton wrote:
> On 7/12/2011 11:43 AM, Stefan Sperling wrote:
>>
>> On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
>>>
>>> If you want to keep it as a mergeable branch (clearly relevant),
>>> then maybe it's better just to add on as "svn
On Mon, Jul 11, 2011 at 1:57 PM, Andy Singleton wrote:
> I received a lot of good comments, and I will batch up my responses in this
> note.
>
> From Stefan, essentially "Can you improve the existing merge"? Yes, I think
> that we can start with the existing merge code.
>
> However, I also think
Log and blame will not be problems. My proposal does not change log
or blame. They will still work fine if you apply newmerge. The
revisions and authors and commit messages are still in the repository in
the same place, and log and blame will still show them.
There are only two cases that
On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard wrote:
>> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
>> wrote:
>>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
Finally, in your new design do not forget about th
On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard wrote:
> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> wrote:
>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>>>
>>> Finally, in your new design do not forget about things like log -g and
>>> blame -g, as well as the mergeinfo comm
On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>>
>> Finally, in your new design do not forget about things like log -g and
>> blame -g, as well as the mergeinfo command. These features are all
>> necessary parts of a merge tracki
On Tue, Jul 12, 2011 at 12:40 PM, Andy Singleton wrote:
> Good point. If we allow foreign merges, then "log" and "blame" are not
> going to work well. They will show changes coming from the merge, rather
> than from the original commit. Fine. I'm willing to give up those details,
> because me
On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>
> Finally, in your new design do not forget about things like log -g and
> blame -g, as well as the mergeinfo command. These features are all
> necessary parts of a merge tracking plan and must have answers from
> the first release.
Really
Andy Singleton wrote on Tue, Jul 12, 2011 at 12:16:26 -0400:
> I am only asking you to give up ONE THING: subtree merginfo. To
> succeed, we have to get rid of both parts of it. We have to get rid
> of the subtree info, and we have to get rid of the fussy little
> merginfo format.
Why is the
On 7/12/2011 12:25 PM, Mark Phippard wrote:
On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton wrote:
Mark, I agree with you that the existing merge will work better if we apply
some restrictions. I can see that the project is already going that way,
and maybe it is good to continue in that di
On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton wrote:
> Mark, I agree with you that the existing merge will work better if we apply
> some restrictions. I can see that the project is already going that way,
> and maybe it is good to continue in that direction. As a user, I would find
> that h
On 7/12/2011 11:54 AM, Mark Phippard wrote:
On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton wrote:
I don't think that we will need to force anyone to give up the old merge.
If and when the newmerge is better, they will migrate on their own. I
think merge is an important concern for many u
On 7/12/2011 11:43 AM, Stefan Sperling wrote:
On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
If you want to keep it as a mergeable branch (clearly relevant),
then maybe it's better just to add on as "svn newmerge" from the
beginning. If that approach is recommended, then maybe
On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton wrote:
> I don't think that we will need to force anyone to give up the old merge.
> If and when the newmerge is better, they will migrate on their own. I
> think merge is an important concern for many users and they will migrate
> quickly if the
On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
> If you want to keep it as a mergeable branch (clearly relevant),
> then maybe it's better just to add on as "svn newmerge" from the
> beginning. If that approach is recommended, then maybe someone can
> help by adding the stub for t
On Jul 12, 2011, at 11:29 AM, Andy Singleton wrote:
> My original idea was to make a new executable file called "newmerge". It
> would be an external script, and if you want to use it, you just need that
> extra script. However, I was planning on building it from the C code that is
> in "svn
My original idea was to make a new executable file called "newmerge".
It would be an external script, and if you want to use it, you just need
that extra script. However, I was planning on building it from the C
code that is in "svn merge" right now, rather than python or perl.
Using the ex
Mark Phippard wrote on Tue, Jul 12, 2011 at 11:00:10 -0400:
> We can just have a way to not allow users to use the features of
> existing merge that we do not want them to use. The existing merge
> command already supports the proposed simple syntax.
+1
On Tue, Jul 12, 2011 at 10:52 AM, Julian Foad wrote:
> A script has the advantage that it could be tried and even rolled out by
> people who are still using 1.6.x.
>
> None of that is a reason not to start a branch.
+1 on the branch. But wouldn't it make sense to defer creating the
branch for a
On 07/12/2011 10:52 AM, Julian Foad wrote:
> Note that there are other possible ways of working, which can be tried
> as well as or instead of the branch. An external script is another good
> option, like the way 'svnmerge.py' existed before the current built-in
> merge tracking. I was talking to
C. Michael Pilato wrote:
> On 07/12/2011 09:40 AM, Hyrum K Wright wrote:
> > We should probably consider having Andrew and his group do their work
> > on a branch in our repository.
>
> +1
+1. I can create a branch, called ... well, the basic nature of this
proposal is simplifying the scope of w
On 07/12/2011 09:40 AM, Hyrum K Wright wrote:
> We should probably consider having Andrew and his group do their work
> on a branch in our repository.
+1
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital s
On Mon, Jul 11, 2011 at 11:51 AM, C. Michael Pilato wrote:
> On 07/11/2011 11:46 AM, Andy Singleton wrote:
>>
>> Many developers are moving from Subversion to other SCM systems that have
>> better merge capabilities. I have posted an article with a proposal to fix
>> this problem, here:
>>
>> htt
On 7/11/2011 3:33 PM, Bob Archer wrote:
If you want to fix Subversion merge there are two issues that have
to
be addressed. If you are not addressing these issues you are just
rearranging the deck chairs on the Titanic.
1. Cyclic merges (the reason we added --reintegrate).
http://subversion.t
> If you want to fix Subversion merge there are two issues that have
> to
> be addressed. If you are not addressing these issues you are just
> rearranging the deck chairs on the Titanic.
>
> 1. Cyclic merges (the reason we added --reintegrate).
>
> http://subversion.tigris.org/issues/show_bug.c
It would be quite nice to have a complete record of all patches
included in a merge. This would be real changeset passing. However,
this would obviously be big and start to reproduce the complete
repository. I think that cyclic merges could be improved by recording
only the edits that you m
Andy Singleton wrote on Mon, Jul 11, 2011 at 13:57:58 -0400:
> Yes, the "cyclic merge" problem is a big one, and along with the
> tree change problem, it accounts for most of the frustrating
> behavior of Subversion merge -
> http://subversion.tigris.org/issues/show_bug.cgi?id=2837
>
> I believe t
I received a lot of good comments, and I will batch up my responses in
this note.
From Stefan, essentially "Can you improve the existing merge"? Yes, I
think that we can start with the existing merge code.
However, I also think that any implementation that uses subtree
merginfo, and does n
On Mon, 2011-07-11 at 12:48 -0400, Mark Phippard wrote:
> 2. Subversion does not handle move/rename well (tree conflicts)
[...]
> When this problem was first approached (before we came up
> with tree conflicts) it hit a brick wall where it seemed a new
> repository design was needed:
It's worth co
On Mon, Jul 11, 2011 at 12:48:27PM -0400, Mark Phippard wrote:
> If you want to fix Subversion merge there are two issues that have to
> be addressed. If you are not addressing these issues you are just
> rearranging the deck chairs on the Titanic.
>
> 1. Cyclic merges (the reason we added --rein
On 07/11/2011 11:46 AM, Andy Singleton wrote:
>
> Many developers are moving from Subversion to other SCM systems that have
> better merge capabilities. I have posted an article with a proposal to fix
> this problem, here:
>
> http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It-s-Time
If you want to fix Subversion merge there are two issues that have to
be addressed. If you are not addressing these issues you are just
rearranging the deck chairs on the Titanic.
1. Cyclic merges (the reason we added --reintegrate).
http://subversion.tigris.org/issues/show_bug.cgi?id=2837
This
Mark Phippard wrote on Mon, Jul 11, 2011 at 12:37:52 -0400:
> On Mon, Jul 11, 2011 at 12:29 PM, Daniel Shahaf
> wrote:
> > Mark Phippard wrote on Mon, Jul 11, 2011 at 12:09:51 -0400:
> >> On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton wrote:
> >> > * It can merge from foreign repositories, and
On Mon, Jul 11, 2011 at 12:29 PM, Daniel Shahaf wrote:
> Mark Phippard wrote on Mon, Jul 11, 2011 at 12:09:51 -0400:
>> On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton wrote:
>> > * It can merge from foreign repositories, and track changes as they move
>> > through foreign repositories (eg clone
On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton wrote:
> Many developers are moving from Subversion to other SCM systems that have
> better merge capabilities. I have posted an article with a proposal to fix
> this problem, here:
>
> http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It
Mark Phippard wrote on Mon, Jul 11, 2011 at 12:09:51 -0400:
> On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton wrote:
> > * It can merge from foreign repositories, and track changes as they move
> > through foreign repositories (eg clones). This is a common case in modern
> > workflows. Changes ha
On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton wrote:
> Many developers are moving from Subversion to other SCM systems that have
> better merge capabilities. I have posted an article with a proposal to fix
> this problem, here:
>
> http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It
On Mon, Jul 11, 2011 at 11:46:11AM -0400, Andy Singleton wrote:
> Many developers are moving from Subversion to other SCM systems
> that have better merge capabilities. I have posted an article with a
> proposal to fix this problem, here:
>
> http://blog.assembla.com/assemblablog/tabid/12618/bid/
44 matches
Mail list logo
