You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Pamio, Diego" <di...@intel.com> on 2007/02/26 14:51:38 UTC
[merge-tracking]: Release date/version
Is there any forecast on which date the merge-tracking feature will be
included in the product? Where can I find this information among the
current status/progress?
Regards and thank you in advance,
Diego N. Pamio
asdc
Argentina Software
Development Center
Intel Software de Arg.
++54 351 414 5571
Re: [merge-tracking]: Release date/version
Posted by Folker Schamel <sc...@spinor.com>.
Daniel Rall wrote:
> On Thu, 08 Mar 2007, Folker Schamel wrote:
>
>>> On Tue, 27 Feb 2007, Folker Schamel wrote:
>>>
>>>>> On 2/26/07, *Justin Johnson* <justinjohnson@gmail.com
>>>>> <ma...@gmail.com>> wrote:
>>>>>
>>>>> What information is available on what this merge tracking will include?
>>>> Just for curiosity:
>>>> (For all our use cases, the features of svnmerge.py are fine.)
>>>>
>>>> When merging something from branch A -> B,
>>>> will merge respect already merged changes B -> A?
>>>> (Like svnmerge.py --bidirectional.)
>>>> Will merge respect already merged changes A -> X -> B or B -> X -> A?
>>>> (Not supported by svnmerge.py.)
>>> The specs can be found here:
>>>
>>> http://subversion.tigris.org/merge-tracking/
>>>
>>> If you can't determine the answer from reading the specs, let us know.
>> Yes, I know these documents.
>> I don't find the particular location again, but I think I found some
>> implementation note indicating that "B -> A" handled.
>> But I didn't find a note dealing with the other cases "A -> X -> B"
>> and "B -> X -> A", so I suppose they are not handled, is this correct?
>
> Great! I'm glad you're already familiar with the documents. Where in
> the documents would you expect to find this information? (I'd like to
> know where to clarify them.)
Good question. Somewhere in "Functional Specification".
Maybe in a new subsection in "Repeated Merge"?
>
> "A -> X -> B" is supported. Merge info is recorded on X for A when
> merging A into X. When merging that same change for X into B, we
> record both the merge info for the merge operation itself, plus merge
> in the merge info from the original merge (from A -> X).
>
> Example:
>
> 1. Run 'X$ svn merge -c 37 A', creating r50.
> 2. X now has merge info of "A:37".
> 3. Run 'B$ svn merge -c 50 X', creating r51.
> 4. B now has merge info of "A:37\nX:50".
>
> Attempts to merge either r37 of A or r50 of X into B will be no-ops,
> since B knows that those change sets have already been merged.
>
>
> I don't follow how you want your "B -> X -> A" case to fit in here.
'B$ svn merge -c1 A', creating r2, merge info of B="A:1"
'X$ svn merge -c2 B', creating r3, merge info of X="B:2\nA:1"
'A$ svn merge -c3 X', is this a no-op?
I suppose it should be, because r3 added "A:1" to the merge info of X.
The B -> A case would be:
'B$ svn merge -c1 A', creating r2, merge info of B="A:1"
'A$ svn merge -c2 B', is this a no-op?
I suppose it should be, because r2 added "A:1" to the merge info of B.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge-tracking]: Release date/version
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 08 Mar 2007, Folker Schamel wrote:
> > On Tue, 27 Feb 2007, Folker Schamel wrote:
> >
> >>> On 2/26/07, *Justin Johnson* <justinjohnson@gmail.com
> >>> <ma...@gmail.com>> wrote:
> >>>
> >>> What information is available on what this merge tracking will include?
> >> Just for curiosity:
> >> (For all our use cases, the features of svnmerge.py are fine.)
> >>
> >> When merging something from branch A -> B,
> >> will merge respect already merged changes B -> A?
> >> (Like svnmerge.py --bidirectional.)
> >> Will merge respect already merged changes A -> X -> B or B -> X -> A?
> >> (Not supported by svnmerge.py.)
> >
> > The specs can be found here:
> >
> > http://subversion.tigris.org/merge-tracking/
> >
> > If you can't determine the answer from reading the specs, let us know.
>
> Yes, I know these documents.
> I don't find the particular location again, but I think I found some
> implementation note indicating that "B -> A" handled.
> But I didn't find a note dealing with the other cases "A -> X -> B"
> and "B -> X -> A", so I suppose they are not handled, is this correct?
Great! I'm glad you're already familiar with the documents. Where in
the documents would you expect to find this information? (I'd like to
know where to clarify them.)
"A -> X -> B" is supported. Merge info is recorded on X for A when
merging A into X. When merging that same change for X into B, we
record both the merge info for the merge operation itself, plus merge
in the merge info from the original merge (from A -> X).
Example:
1. Run 'X$ svn merge -c 37 A', creating r50.
2. X now has merge info of "A:37".
3. Run 'B$ svn merge -c 50 X', creating r51.
4. B now has merge info of "A:37\nX:50".
Attempts to merge either r37 of A or r50 of X into B will be no-ops,
since B knows that those change sets have already been merged.
I don't follow how you want your "B -> X -> A" case to fit in here.
Thanks, Dan
Re: [merge-tracking]: Release date/version
Posted by Folker Schamel <sc...@spinor.com>.
> On Tue, 27 Feb 2007, Folker Schamel wrote:
>
>>> On 2/26/07, *Justin Johnson* <justinjohnson@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> What information is available on what this merge tracking will include?
>> Just for curiosity:
>> (For all our use cases, the features of svnmerge.py are fine.)
>>
>> When merging something from branch A -> B,
>> will merge respect already merged changes B -> A?
>> (Like svnmerge.py --bidirectional.)
>> Will merge respect already merged changes A -> X -> B or B -> X -> A?
>> (Not supported by svnmerge.py.)
>
> The specs can be found here:
>
> http://subversion.tigris.org/merge-tracking/
>
> If you can't determine the answer from reading the specs, let us know.
Yes, I know these documents.
I don't find the particular location again, but I think I found some
implementation note indicating that "B -> A" handled.
But I didn't find a note dealing with the other cases "A -> X -> B"
and "B -> X -> A", so I suppose they are not handled, is this correct?
Thanks!!
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge-tracking]: Release date/version
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 27 Feb 2007, Folker Schamel wrote:
> > On 2/26/07, *Justin Johnson* <justinjohnson@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > What information is available on what this merge tracking will include?
>
> Just for curiosity:
> (For all our use cases, the features of svnmerge.py are fine.)
>
> When merging something from branch A -> B,
> will merge respect already merged changes B -> A?
> (Like svnmerge.py --bidirectional.)
> Will merge respect already merged changes A -> X -> B or B -> X -> A?
> (Not supported by svnmerge.py.)
The specs can be found here:
http://subversion.tigris.org/merge-tracking/
If you can't determine the answer from reading the specs, let us know.
Re: [merge-tracking]: Release date/version
Posted by Folker Schamel <sc...@spinor.com>.
> On 2/26/07, *Justin Johnson* <justinjohnson@gmail.com
> <ma...@gmail.com>> wrote:
>
> What information is available on what this merge tracking will include?
Just for curiosity:
(For all our use cases, the features of svnmerge.py are fine.)
When merging something from branch A -> B,
will merge respect already merged changes B -> A?
(Like svnmerge.py --bidirectional.)
Will merge respect already merged changes A -> X -> B or B -> X -> A?
(Not supported by svnmerge.py.)
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[merge tracking] Granularity of merge history
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 26 Feb 2007, Justin Johnson wrote:
...
> >> Specifically I am wondering if it will track merges on a file by file
> >> basis, or will it be something like svnmerge.py's top level property
> >> that tracks previous merges of the entire branch? If it is on a file
> >> by file basis then users could merge their changes to a handful of
> >> files, and someone in a merge manager role could still perform the
> >> merge for the entire branch, which would then skip merges previously
> >> done on those handful of files.
...
> >http://subversion.tigris.org/merge-tracking/index.html
...
> >It is like svnmerge.py, although my understanding is that it should also
> >handle the case you cite.
>
> Will it handle the case when a user merges a changeset from one branch
> to another, but only accepts some of the changes in the changeset?
> For example, if a changeset modified two files and the user merged
> (cherry picked) the changes made to one of the files from branch A to
> branch B, will that merge be tracked?
>
> If that will be tracked, is the property stored on the individual file?
>
> My use of svnmerge.py is minimal at this point, but in my testing I
> did a merge and then reverted some of the changes that resulted from
> the merge before committing. But since the merge tracking was in a
> property on the top level directory (i.e. the branch) the state of the
> merge and the tracking information were inconsistent. The tracking
> information said I had merged a particular changeset in full, but my
> revert resulted in only partially merging the changeset.
>
> I was hoping that the merge tracking would be stored on the file so
> that if I revert the changes on the file, or if I only merge part of a
> changeset to begin with, merge tracking remains consistent with
> reality.
The merge history for Subversion's Merge Tracking is inherited, and
tracked at the appropriate level of granularity. Sometimes this is at
the file-level.
In other words, it does the Right thing.
Re: [merge-tracking]: Release date/version
Posted by Justin Johnson <ju...@gmail.com>.
> > What information is available on what this merge tracking will include?
> >
> > Specifically I am wondering if it will track merges on a file by file
> > basis, or will it be something like svnmerge.py's top level property
> > that tracks previous merges of the entire branch? If it is on a file
> > by file basis then users could merge their changes to a handful of
> > files, and someone in a merge manager role could still perform the
> > merge for the entire branch, which would then skip merges previously
> > done on those handful of files.
>
> Docs are on the web site
>
> http://subversion.tigris.org/merge-tracking/index.html
Thank you. I should have looked a little harder before asking.
> It is like svnmerge.py, although my understanding is that it should also
> handle the case you cite.
Will it handle the case when a user merges a changeset from one branch
to another, but only accepts some of the changes in the changeset?
For example, if a changeset modified two files and the user merged
(cherry picked) the changes made to one of the files from branch A to
branch B, will that merge be tracked?
If that will be tracked, is the property stored on the individual file?
My use of svnmerge.py is minimal at this point, but in my testing I
did a merge and then reverted some of the changes that resulted from
the merge before committing. But since the merge tracking was in a
property on the top level directory (i.e. the branch) the state of the
merge and the tracking information were inconsistent. The tracking
information said I had merged a particular changeset in full, but my
revert resulted in only partially merging the changeset.
I was hoping that the merge tracking would be stored on the file so
that if I revert the changes on the file, or if I only merge part of a
changeset to begin with, merge tracking remains consistent with
reality.
I probably should have started a new thread for this.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge-tracking]: Release date/version
Posted by Mark Phippard <ma...@gmail.com>.
On 2/26/07, Justin Johnson <ju...@gmail.com> wrote:
>
> What information is available on what this merge tracking will include?
>
> Specifically I am wondering if it will track merges on a file by file
> basis, or will it be something like svnmerge.py's top level property
> that tracks previous merges of the entire branch? If it is on a file
> by file basis then users could merge their changes to a handful of
> files, and someone in a merge manager role could still perform the
> merge for the entire branch, which would then skip merges previously
> done on those handful of files.
Docs are on the web site
http://subversion.tigris.org/merge-tracking/index.html
It is like svnmerge.py, although my understanding is that it should also
handle the case you cite.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [merge-tracking]: Release date/version
Posted by Justin Johnson <ju...@gmail.com>.
What information is available on what this merge tracking will include?
Specifically I am wondering if it will track merges on a file by file
basis, or will it be something like svnmerge.py's top level property
that tracks previous merges of the entire branch? If it is on a file
by file basis then users could merge their changes to a handful of
files, and someone in a merge manager role could still perform the
merge for the entire branch, which would then skip merges previously
done on those handful of files.
Thanks,
Justin
On 2/26/07, Daniel Rall <dl...@collab.net> wrote:
> On Mon, 26 Feb 2007, Pamio, Diego wrote:
>
> > Is there any forecast on which date the merge-tracking feature will be
> > included in the product? Where can I find this information among the
> > current status/progress?
>
> Diego, the current plan is to release Merge Tracking with Subversion
> 1.5.0. While a project like Subversion which is staffed mostly by
> volunteers can't easily make meaningful commitments to release dates,
> as one of the developers working on the merge-tracking branch, I
> personally expect 1.5.0 to be released by Q3 2007.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: [merge-tracking]: Release date/version
Posted by "Pamio, Diego" <di...@intel.com>.
Ok, great, that kind of ROM estimates was what I needed.
-----Original Message-----
From: Daniel Rall [mailto:dlr@collab.net]
Sent: Monday, February 26, 2007 2:55 PM
To: Pamio, Diego
Cc: dev@subversion.tigris.org
Subject: Re: [merge-tracking]: Release date/version
On Mon, 26 Feb 2007, Pamio, Diego wrote:
> Is there any forecast on which date the merge-tracking feature will be
> included in the product? Where can I find this information among the
> current status/progress?
Diego, the current plan is to release Merge Tracking with Subversion
1.5.0. While a project like Subversion which is staffed mostly by
volunteers can't easily make meaningful commitments to release dates,
as one of the developers working on the merge-tracking branch, I
personally expect 1.5.0 to be released by Q3 2007.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [merge-tracking]: Release date/version
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 26 Feb 2007, Pamio, Diego wrote:
> Is there any forecast on which date the merge-tracking feature will be
> included in the product? Where can I find this information among the
> current status/progress?
Diego, the current plan is to release Merge Tracking with Subversion
1.5.0. While a project like Subversion which is staffed mostly by
volunteers can't easily make meaningful commitments to release dates,
as one of the developers working on the merge-tracking branch, I
personally expect 1.5.0 to be released by Q3 2007.