Re: Soc: cayenne-rop

[Andrus Adamchik <an...@objectstyle.org>]

Let's move the SVK discussion to the mailing list. Admittedly I  
haven't used SVK myself, so maybe Kevin can comment on the practical  
aspects.

The idea is that the students initially will only have read access to  
the master repository at Apache. This follows a normal pattern of  
working with new open source contributors - before write access is  
granted (i.e. a person becomes a project committer), (s)he needs to  
build some "karma" within the project community. Until then all the  
contributions are accepted as patches.

Yes, patch is a text file in a standard format generated by the unix  
"diff -u" command (and can be applied using unix "patch" command).  
Subversion, CVS, Eclipse and many other tools support this format (in  
Eclipse you can both generate and apply standard patches).

The idea of a local repository was proposed to help with SoC work  
because you can actually generate a patch between two different local  
revisions. So you can submit any number of incremental patches to  
your mentor without having to wait until the earlier patches are  
reviewed and committed to the master repo.

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?

Andrus




On May 26, 2006, at 1:44 AM, Marcel wrote:
> Andrus,
>
> I'm a little unsure about the relationship between Jira and an SVK  
> repository.
>
> From the thread, I take it that using SVK would help because 1) I  
> would then be working in a source control system, with all the  
> associated benefits and 2) I could submit patches much more easily.  
> The first part I understand; however with the second, does a patch  
> come in a standard format, extractable from SVK?
>
> If that is the case, I'm happy to work that way, but if it possible  
> without too much trouble I would prefer to have a sub-branch on a  
> remote repository - even if it is a separate place from where my  
> code goes after review through JIRA - as that would protect me from  
> local failures (a big part of benefit (1)). Additionally, it would  
> be a better fit with the 'open development' model as you guys have  
> been discussing.
>
> Marcel

Re: Soc: cayenne-rop

[Andrus Adamchik <an...@objectstyle.org>]

I certainly do not want to force anybody to SVK, and we can easily  
accommodate a sandbox repository. I just created SVN space @ObjectStyle:

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  
>> <an...@objectstyle.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
>>
>

Re: Soc: cayenne-rop

[Marcel <em...@gmail.com>]

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 
> <an...@objectstyle.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
>

Re: Soc: cayenne-rop

[Kevin Menard <km...@servprise.com>]

On Fri, 26 May 2006 11:11:37 -0400, Andrus Adamchik  
<an...@objectstyle.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