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