Sean Moss-Pultz wrote:
> On 2005/11/16, at 下午 3:31, Mike Dewhirst wrote:
>
>> Sean Moss-Pultz wrote:
>>
>>> My team is planning about a 2 to 3 week field test during which we
>>> will need to maintain a synced code base. Currently we are using
>>> subversion but we will not have access to this server on the road.
>>
>>
>> Presumably, other teams will be working and making changes while you
>> are away.
>>
>> IMHO the easiest solution would be to set up a new cheap subversion
>> server on a retired PC reformatted to run Linux off a magazine cover.
>> If you serve via apache you can set it up so everyone has
>> authenticated access from anywhere. The people left behind can cache
>> their logins for convenience.
>
>
> We are all going to be using notebooks. my is a powerbook so i could
> easily install a subversion server but then I'm not sure if it's
> possible to merge this new repository back into our existing one at
> work. It would be very important for us as work would be done on both
> repositories. Do you know if this would be possible?
>
> This is why I was thinking SVK could be a good solution.
Afaik, SVN assumes a single central repository (it is designed as a
centralized VCS), so doing parallel development on separate SVN repos and then
trying to merge may cause trouble.
The only way I see to handle this using SVN only is to consider the moment you
are copying the code for downloading into the laptops as an (internal) release
(which I assume to be a branch, since you will supply bugfixes (see below)).
You (as customer of the release) can get the code, and do anything with it you
like, including creating your own repo and hacking^H^H^H^H^H^H^Himproving it.
When you return, you should be able to merge back changes as a serie of patches.
Insert these patches back to the release branch (which should be without any
problem, if nobody else in the company touches the release branch), then merge
changes back to the trunk.
I am not an SVN wizard, so I have no idea how to do the above for each
revision in a different repository (preferably with the preservation of the
log message, I assume), but maybe someone else on the list can help you with that.
With respect to SVK, I have no experience whatsoever with it, but it states
that it is a decentralized VCS, which is in essence what you need here, so
that may work.
The catch may be here that SVK may assume that everybody is using SVK rather
than SVN (ie it may treat SVN as its private backend which is supposed to be
changed only through SVK). You may want to ask about this to the SVK
users/developers.
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 16 10:06:09 2005