[svk-devel] Why push svk:mirror?

[Michael Brouwer]

svk:merge tickets are uid:path:rev tuples.  A given uid:path combination
will only ever show up once in a given svk:merge property.  The rev part
always indicates the last rev (in the rev space of the mirror source) that
was merged into the directory with the svk:merge property on it.

Since your local mirror will have a different uid than someone elses local
mirror, the svk:merge property will contain a separate entry (line) for each
merge (even if the local path names you and someone else picked happen to be
the same).  This allows for correct repeated merges from either your or
someone elses local mirror in the future.

Michael

On 2/26/07, Viktor Štujber <theultramage at gmail.com> wrote:
>
> I can imagine that things would go wrong when
> 1. I smerge from local to mirror (the local path gets recorded)
> 2. someone else then smerges from his local branch to mirror
>
> How will svk handle this? Add another prop? Overwrite the old one
> based on the uID? Or accept the meta info which doesn't match at all?
>
> On 2/26/07, Chia-Liang Kao <clkao at clkao.org> wrote:
> > > I am a bit puzzled about the svk:mirror property. I understand why it
> is
> > > needed, but why is it pushed to the upstream server? When mirroring a
> > > server, the information about the merge status is only relevant for
> the
> > > local copy, not for the upstream server. At least I do not see how he
> > > can make use of it, any the local repository knows anyway.
> >
> > ITYM svk:merge?  you can use --no-ticket on merge operations, but svk
> > won't be able to do smart merge at all.
> >
> > > In fact I would find it much more pleasant if svk:mirror would only be
> > > stored locally: First, it would make svk usage completely transparent
> > > (to the upstream server), svk would just be a much more powerful svn
> > > client.  And second, the svk:mirror property grows with the number of
> > > svk users (i.e. developer), which is unaesthetic. Admittedly these are
> > > not real problems, but I would still think a solution without upstream
> > > svk:mirror nicer.
> >
> > The reason the merge meta data are in the mirror is because you don't
> > just merge between branches in your local depot, there could be merges
> > between published branches.  And not storing the meta data or only
> > having it overlaying on the local mirror will make it impossible for
> > other svk users to perform smart merges.
> >
> > Cheers,
> > CLK
> > _______________________________________________
> > svk-devel mailing list
> > svk-devel at bestpractical.com
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
> >
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/svk-devel/attachments/20070226/3fbfe82d/attachment.htm