Amir Kolsky wrote:
<snip>
>location. If someone rebuilt A.SLN and committed, A.DLL would have been
>changed, and it will be refreshed in the next update. If I have also changed
>A.DLL then we'll run into a conflict. This conflict can not be solved by a
>merge, as we are not dealing with text here. The solution is to:
> Locally delete (or revert) the conflicted file and all conflict-related
>junk (i.e. Resolve Conflict),
> Update, and
> Rebuild.
>This will make A.DLL changed with respect to HEAD rather than conflicted,
>and life can go on.
>
Aha! I recognize this usage pattern from projects at my last employer.
There is a general golden rule
of not versioning derivate. In your case the binary dll files are
derivate of the source code. The path
chosen, while inviting at first, will continue to give you troubles
endlessly. In certain cases you could
probably work around it, or live with it though, but I recommend against it.
The main argument against versioning derivate is that you no longer know
which code is the current
code. Is it the source code or is it the binaries? When tests fail,
where do you look for the bug, in
the source or the binaries? What version of the source do the binaries
come from? Believe me when
I say that this road leads to dismay.
The solution I choose to work around this was to remove all binaries
from versioning and have all
devs compile all code. That is also a basic requirement in XP. This lead
to pretty long build times
so we ended up having the possibility to synchronize the basic libraries
via a central build and our
build scripts. This worked very well and it was greatly appreciated from
devs that there was such
a hard and consistent rule about what to version and what not to.
If you decide to ignore the above you still need to resolve the
conflicts. My advice would be to
set the svn meta data property 'svn:mime-type' to something other then
'text/...', e.g.
'application/octet-stream'. This will tell svn that the files are
'unmergable' that is, they can't use
a normal diff editor such as TMerge but instead you have to manually
select one of the files over
the other, or replace them with a third.
In your case this should be trivial since the update already gave you
the new source, the binaries
are of no use to you. Just mark all binaries as resolved and recompile
the source again and commit.
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Apr 15 13:06:16 2005