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 : Sun May 28 2006 - 20:52:45 EDT