[sip-comm-dev] GSoC Branches


#1

Hey all,

A quick note for all GSoC students and mentors.

We are now ready to start creating GSoC branches. If you feel that you'd
need one, drop me (personally or on dev) a note with your java.net user
name.

Keep in mind however that working on a branch has the disadvantage of
making updates a lot trickier. Following changes in trunk becomes more
complicated since you won't be able to simply "svn update" any longer
and would have to "svn merge" instead.

This is a bit problematic since the SVN version currently offered by
java.net is 1.4 so there's no support for merge tracking in there. This
basically means that if any conflicts appear in classes that have been
modified by both you and an SC developer, you would have to manually
resolve them every time you merge (and not only once as with merge
tracking or "svn update").

Having said this, committing changes to a branch has the obvious
advantage of offering backup, and making them available to others for an
early review.

In the end of the day, it's really about what you need and what suits
you best, so let me know.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Emil,

I would like to have a branch for my project.
My java.net username is : ajay_chhatwal

Regards

Ajay

···

On Sat, Jun 13, 2009 at 6:01 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey all,

A quick note for all GSoC students and mentors.

We are now ready to start creating GSoC branches. If you feel that you'd
need one, drop me (personally or on dev) a note with your java.net user
name.

Keep in mind however that working on a branch has the disadvantage of
making updates a lot trickier. Following changes in trunk becomes more
complicated since you won't be able to simply "svn update" any longer
and would have to "svn merge" instead.

This is a bit problematic since the SVN version currently offered by
java.net is 1.4 so there's no support for merge tracking in there. This
basically means that if any conflicts appear in classes that have been
modified by both you and an SC developer, you would have to manually
resolve them every time you merge (and not only once as with merge
tracking or "svn update").

Having said this, committing changes to a branch has the obvious
advantage of offering backup, and making them available to others for an
early review.

In the end of the day, it's really about what you need and what suits
you best, so let me know.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Done,

https://sip-communicator.dev.java.net/svn/sip-communicator/branches/gsoc09/db-history/

Starting from r5376.

Also, user ajay_chhatwal now has the GSoCDeveloper role. Use it wisely :wink:

Cheers
Emil

AJAY CHHATWAL wrote:

···

Hi Emil,

I would like to have a branch for my project.
My java.net username is : ajay_chhatwal

Regards

Ajay

On Sat, Jun 13, 2009 at 6:01 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey all,

A quick note for all GSoC students and mentors.

We are now ready to start creating GSoC branches. If you feel that you'd
need one, drop me (personally or on dev) a note with your java.net user
name.

Keep in mind however that working on a branch has the disadvantage of
making updates a lot trickier. Following changes in trunk becomes more
complicated since you won't be able to simply "svn update" any longer
and would have to "svn merge" instead.

This is a bit problematic since the SVN version currently offered by
java.net is 1.4 so there's no support for merge tracking in there. This
basically means that if any conflicts appear in classes that have been
modified by both you and an SC developer, you would have to manually
resolve them every time you merge (and not only once as with merge
tracking or "svn update").

Having said this, committing changes to a branch has the obvious
advantage of offering backup, and making them available to others for an
early review.

In the end of the day, it's really about what you need and what suits
you best, so let me know.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net