On Thu, 14 Oct 2010 22:33:04 +0200, Stefan Sperling wrote:
> On Thu, Oct 14, 2010 at 09:55:08PM +0200, Olivier Sannier wrote:
>> On 14/10/2010 21:45, Dan Nessett wrote:
>> >On Thu, 14 Oct 2010 15:38:41 -0400, Bob Archer wrote:
>> >>>Generally, (using subversion) we
>> >>>check out a tagged version into a workspace, recursively delete the
>> >>>.svn directories, modify a small number of files, add some of our
>> >>>own extensions, and then commit the result into our own repository.
>> >>>We then work with the source from there.
>
>> >>There is a whole section in the svn book about this...
>> >>
>> >>http://svnbook.red-bean.com/nightly/en/svn-
book.html#svn.advanced.vendorbr
>
>> >I have read this section. It is about vendor drops, but it doesn't
>> >answer the question I asked. Basically, we are doing a vendor drop
>> >now.
>
> It doesn't sound like you're using the approach described in the book.
>
> With vendor branching, you work with 2 distinct branches, one containing
> pristine upstream vendor code, and one containing the modified version.
> Rather than adding the upstream source code mixed up with your own
> modifications directly.
>
> You might also want to take a look at Piston:
> http://piston.rubyforge.org/
>
> Stefan
Yes, you're right. We don't store an exact copy of each drop in our
repository. Instead, we copy the drop into a workspace (effectively
importing by checking out and then recursively deleting the .svn
directories), merge there and commit to the new version. We couldn't
understand why we need to keep an exact copy of the vendor drop in our
repository.
Piston looks interesting, but it also appears to require ruby. This isn't
a show stopper, but it would be nice if we could do what we want to do
with subversion only. If that isn't possible, or it is too complex, then
Piston might be the right way to go.
Dan
--
-- Dan Nessett
Received on 2010-10-14 22:53:51 CEST