Jason Butlin wrote:
>
>
>> From: Martin Tomes <lists@tomes.org>
>> To: Jason Butlin <roguejay@hotmail.com>
>> CC: users@subversion.tigris.org
>> Subject: Re: Patch/Diff
>> Date: Tue, 19 Jul 2005 10:05:00 +0100
>>
>> Jason Butlin wrote:
>>
>>> We have a set of circumstances at work that has made me look into
>>> ways of providing an alternative form of remote working for our
>>> developers. I thought I'd come up with a solution, but it would
>>> appear that the diff/patch tools are not quite up to the task.
>>
>>
>> Have you looked at SVK? It sounds like it might help you.
>>
>> --
>> Martin Tomes
>
>
> Cheers. I've had a little look at this before, but there are 2 problems
> I see with this. Firstly, it's built against 1.1.4 of SubVersion and we
> use 1.2, so there may be issues there.
>
I'm using SVK with 1.2 right now with no problems.
> The other is that from what I can gather, SVK works by ultimately
> connecting to the central repository. This would be great for laptop
> users that can bring their laptops into work every now and then, but our
> users would be developing on hoem PCs. The only connection the remote
> worker has with the office is email (or an FTP dumping area). So I'm not
> sure how the users would communicate their changes back and forth, or
> get those from the office either.
>
I'm not overly familiar with this model of working, but I think you'd do
it like this:
1. Each developer creates a local repository, and loads a dump of the
live repository into it.
2. Mirror the repository in SVK.
3. Create a local branch in SVK and work off that.
4. User's receive patches via email and apply them to the trunk.
Developers pull to their local branch to get the changes.
5. Developer pushes but creates a patch instead of actually merging to
trunk. Developer emails change to repository.
6. The developer's patch eventually gets filtered back to them in stage
4., but SVK won't pull it into the local branch because it knows it's
already got it.
7. Repeat and rinse as required.
As I say, this might not be completely correct, but I think that's
roughly how it would work.
> Jay
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 19 15:21:20 2005