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
<[EMAIL PROTECTED]> 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
