I certainly do not want to force anybody to SVK, and we can easily
accommodate a sandbox repository. I just created SVN space..bjectStyle:
https://svn.objectstyle.org/repos/soc/trunk/
Use you Confluence login id and password to commit code. Other SoC
students also have access to this sandbox with their Confluence
credentials.
Hopefully this'll make life easier. Just keep in mind that this
repository is not "official", i.e. the sandbox is for your use only,
and the code still has to be submitted as patches via Jira.
Andrus
On May 28, 2006, at 8:52 PM, Marcel wrote:
> Any further on this?
>
> My preference (FWIW) is to have a pseudo-branch with commit
> privileges. I should still have to submit patches through JIRA, in
> line with the 'typical path to karma' - I don't wish to shortcut
> that, I would just prefer that my repository is remote. My patches
> would then be reviewed and the real branch updated. Thoughts?
>
> Marcel
>
> Kevin Menard wrote:
>> On Fri, 26 May 2006 11:11:37 -0400, Andrus Adamchik
>> <andru..bjectstyle.org> wrote:
>>
>>> Again, I don't know if SVK offers benefits compared to Subversion
>>> in synchronizing your work with master Subversion instance (I
>>> guess I have to try it myself). Kevin, do you have any practical
>>> hints on using SVK in this scenario?
>>
>> I've only been using SVK for a few days now, but so far it's been
>> pretty nice to me. Basically what you do is create a mirror of
>> the main SVN repository (going back as far as you'd like) and then
>> a local workspace from that mirror. The mirrored workspace can
>> 'sync' with the primary SVN repository no problem. As you commit
>> to the local workspace, you can 'smerge' changes back to the
>> mirrored workspace. So, it does work bi-directionally.
>> Unfortunately, I haven't seen how this works in non-trivial cases,
>> but it should work just like SVN would (SVK uses SVN for all of
>> its internal versioning).
>>
>> I haven't yet tried to create a patch since I have commit privs on
>> my server. I'll play around with this a bit more though over the
>> weekend and post my findings on Confluence.
>>
>> My personal preference would still be if they had their own
>> branch. SVK is nice, but the 3rd party tool support is lacking.
>> That means no TortoiseSVN or SVN plugins for Eclipse/IDEA/
>> NetBeans, which is a major disadvantage IMHO. But then again, I
>> can see the need to follow the typical ASF path to karma.
>>
>> --Kevin
>>
>
This archive was generated by hypermail 2.0.0 : Mon May 29 2006 - 16:45:52 EDT