I get your point Amir, however, as I've written in answers here before,
you are working against
the flow here. The basic problem you're having is versioning dll's that
you have already the
source for. There are a few solutions to that problem, all kind of small
hacks, but they work.
Using svn for it has turned out to be a bad solution (I also found out
the hard way).
In your case you would have to resolve the conflict manually by
selecting the version from HEAD.
An error prune and potentially tedious task.
The main reason I would argue against putting an option in would be in
maintaining the
ability to trace versions. In your case, if you find a bug where do you
go off to find the code
that caused it? Is it the dll's? If it's the dll's, what source code
where they built from?
I argue that such an option would make it easier to adopt development
procedures that would
remove tracability making it very much harder, if not impossible to
reproduce bugs.
The standard work-around would be to handle resulting binaries using
build scripts and
file shares. The one who builds also updates the file share with new
dll's, the downstream
users get's them refreshed automatically via his/her build script.
Also I've seen it work with internal releases where the application is
so large it consists
of a framework, framework applications and enduser application.
Procedures can then
be developed where framework dll's are internally delivered using what
svn calls
vendor branches, http://svnbook.red-bean.com/en/1.1/ch07s04.html.
This type of procedure has the advantage of reducing the code mass
checked out as
a WC should only contain the code for that specific work task, be it
framework or
enduser application. E.g. svn don't compile httpd, it merely uses it's
dll's and hence
avoids the need of having svn devs checkout not only svn code but httpd
code as well.
The drawback would be more procedures needed to make it work.
I'd like to encurage you to also post at svn users list since there is
probably a lot more
solutions to your problems available there. You may wan't to search
their archives first.
/Nicke
Amir Kolsky wrote:
>I see what you guys are saying.
>
>My problem is not the merge, but the conflict. We have a very large
>repository with several solutions in it. Since not everyone builds all the
>solutions at all times (takes too long) we have to version some of the
>binaries into a common location (usually the project directory).
>
>What I'm looking for (which might not be the right thing to do, but...) is a
>way to not have svn tell me that there's a conflict between my dll and the
>one in the head, but let me use the one from the HEAD automatically. This is
>because in almost all cases, I will rebuild the solution and have the WC
>updated immediately.
>
>I asked to be able to do this manually from the update dialog - i.e., see
>that there is a conflict - rmb on the conflicted file - select 'use HEAD'
>and presto - the conflict is resolved. It would also be ok if it were done
>automatically via svn. I don't want to have to do it manually...
>
> Amir Kolsky
>XP& Software
>
>
>
>
>>-----Original Message-----
>>From: Nicklas Norling [mailto:exinor@exinor.net]
>>Sent: Sunday, May 01, 2005 9:21 PM
>>To: dev@tortoisesvn.tigris.org
>>Subject: Re: [TSVN] Application/octetstream
>>
>>Amir Kolsky wrote:
>>
>>
>>
>>>Someone suggested that with said mime type svn will not attampt a
>>>merge. Well, .dll are automatically given this type and
>>>
>>>
>>merge is still
>>
>>
>>>attempted. Any ideas?
>>>
>>> Amir Kolsky
>>>XP& Software
>>>
>>>
>>>
>>I think that might have been me. I also think I told you that
>>it will still need a merge, but that it will leave the binary
>>files on disk in all it's versions and expect you to check
>>them out and merge manually.
>>Well, that's assuming you've actually made local changes,
>>otherwise svn can just replace the file.
>>
>>When you say 'merge is still attempted', what exactly do you mean?
>>
>>B.t.w. it's not a good idea to version dll's if you have the
>>corresponding source code in the repo, but that's unrelated.
>>
>>/Nicke
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon May 2 13:53:24 2005