Hello,
Thank you for your response. I'm glad there are some with things to say
about what I'm working on.
I am looking at using the svk property. I understand that there is
value to reusing the work that they have already done. At the moment I
don't think that it contains quite enough information. For example, I
think its important to store the start revision as well as the end
revision. Currently, the information that I consider important is this:
uuid1, path1@rev, startrevnum
uuid2, path2@rev, endrevnum
This information would be included in a property in the local working
directory to be commited with the rest of the changes. The property is
attached to the target of the merge (wether it be a directory or file).
uuid identifies the repository independant of the access method.
Storing the URL would not do.
path@rev is the path (e.g. /trunk, /branches/branch, etc...) in the
repository to the directory or file of the two sources. The @rev is
necessary in case the file or directory moves later on. By the way, I'm
playing in the code right now. Could someone tell me how I can parse a
URL into path_to_repository, path_inside_repository?
startrev and endrev are just what you think.
Since this information doesn't line up exactly with the svk merge ticket
I thought it would be best to come up with a new property name that
won't conflict with svk. A possible win here is that this property will
contain a superset of the svk merge ticket. So, in theory, svk could
easily be modified to make use of it if it finds it.
I plan to do a follow up post with some more thoughts that I have soon.
I'm currently trying to gather my thoughts in the little bit of time
that I have.
Cheers,
Carl
On Tue, Mar 29, 2005 at 08:47:25AM +0200, Ph. Marek wrote:
> On Saturday 26 March 2005 07:45, Carl Baldwin wrote:
> > I read up on the various things that people pointed me to. Thank you
> > again for your input. It seems that people have a lot of different
> > ideas for tracking merges. This does, indeed, appear to be a big job.
> >
> > I would propose a place to start working on this problem.
> Thank you for volunteering!
>
> > ...
> I see that you already know about svk, and so I beg you to use (if that's at
> all possible) to use the same property name and value, to achive
> interoperability.
>
> But if the goals (or means) are too different, you might need another
> property.
>
>
> Regards,
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 06:43:46 2005