Mark Phippard wrote:
> Joseph Galbraith <galb@vandyke.com> wrote on 01/19/2005 01:14:21 PM:
>
>
>>Would it be possible to get around this problem by properly
>>timing the 'property' update. I.e., TSVN first performs the
>>merge operation, potentially updating the 'merge parameters'
>>property with the information from the branch.
>>
>>However, it then 'overwrites' the property, potential pulled
>>with the merge, with the correct information for the merge
>>now being performed. (TSVN might have to silently resolve
>>conflicts in the 'merge parameters' property.) I guess
>>this might cause problems if a merge were ever done outside
>>of TSVN though.
>>
>>This case definitely complicates things.
>
>
> I think you would still get a property conflict and those are handled kind
> of "oddly". It would be difficult to auto-resolve because there could be
> other properties.
>
>
>>What are the constraints on a property name? Another
>>potential resolution would be to embed the MD5 hash
>>of the relative path of the merge target in the property
>>name.
>
>
> Not sure, but I was thinking an MD5 hash would also work. I have not done
> much with them, if I generate one in Java and someone else in C do we get
> the same value?
Ohh yes. For a given input, there is exactly on valid output (in all
programming languages on all platforms.) The output will always
be exactly 16 bytes long (you'd probably have to hexadecimal
encode it for a total of 32 bytes.)
I don't know if the subversion libraries expose it, but subversion
does use MD5 hashs internally...
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Jan 19 20:01:18 2005