Where to put the Android Code....

7 views
Skip to first unread message

Brad

unread,
Jan 26, 2011, 11:41:17 PM1/26/11
to domuslink-developers
Now that I have a good base for the Android code, where to put it on
google code?

Two Options:

1) Re-factor the current structure to have a top level for the php
code base and another level for the android app. This will cause some
difficulty in merging some open branches unless we do those merges
first, then re-factor.

2) Create a new google code project to hold the Android application.
Unfortunately, the 2 sets of code are in different places.

Thoughts?

Brad

Philippe CARLIER

unread,
Jan 27, 2011, 3:25:14 AM1/27/11
to domuslink-...@googlegroups.com
Hi Brad,

I prefer the second solution.
Android application and Server application should be modified separately.


> Thoughts?
>
> Brad
>

Brad

unread,
Jan 27, 2011, 1:52:55 PM1/27/11
to domuslink-...@googlegroups.com
The only thing about having a separate google code area is that it makes it disconnected from the code tree for what is "domus.Link". I know it seems strange, but the svn structure does not have to be tied to a release structure. Also, you can check out part of a tree and not touch the rest.

Example:

svn:domus.Link
     |- PHP domus.Link Server
     |    |- admin
     |    | - api
     |    |- (etc)
     |- Android Application
     |    |- src
     |    |- res
     |    |- (etc)
     |- iPhone Application
          |- src
          |- (etc)

Brad

unread,
Jan 28, 2011, 4:29:43 PM1/28/11
to domuslink-...@googlegroups.com
Ok, after further SVN research, I have a solution to keep it in the same code area but it will look separate to you. my previous examples assumed it was under /trunk or /branch. SVN checkouts are always to a targeted directory any way and the repository really doesn't care where in the tree it exists.

svn:domus.Link
     |- branches
     |- tags
     |- trunk

     |    |- admin
     |    | - api
     |    |- (etc)
     |- Android Application
     |    |- branches
     |    |- tag
     |    |- trunk
     |- iPhone Application
          |- branches
          |- tag
          |- trunk

So, does that make sense?

Brad

Istvan Cebrian

unread,
Jan 28, 2011, 8:56:49 PM1/28/11
to domuslink-...@googlegroups.com
Hello Brad,

Why not:

svn:domus.Link
|- branches
| |- server
| |- android
| |- iphone
|- tags
| |- server
| |- android
| |- iphone
|- trunk
| |- server
| |- android
| |- iphone

I know this requires a few moves but if everyone checks in all code,
we agree on a code freeze for a certain time period I believe this is
doable.

Regards,

> --
> You received this message because you are subscribed to the Google Groups
> "domuslink-developers" group.
> To post to this group, send an email to
> domuslink-...@googlegroups.com.
> To unsubscribe from this group, send email to
> domuslink-develo...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/domuslink-developers?hl=en-GB.
>

Brad

unread,
Jan 28, 2011, 10:43:12 PM1/28/11
to domuslink-...@googlegroups.com
So, Subversion is a system that creates versions at the level you check them out as. There is no rule in subversion that says this is the structure you have to checkout from. We just were following the previous layouts of other single projects. Such as we don't check out trunk itself, it's just the starting point of the tree and we version the files underneath that point. We don't version the directory trunk or branches or tags, we version the files underneath those points.

In the interest of keeping those tree's as they are since we have been working with them, we can create different trees to accommodate anything else. Also, it will look completely separate as well and we don't have to muck with what you have started for the main domus.Link code.

Thoughts?

Brad

Brad

unread,
Jan 28, 2011, 10:50:30 PM1/28/11
to domuslink-...@googlegroups.com
Sorry, just another thought on how subversion works.

We could checkout and modify as a branch only the admin directory of domus and merge it into another directory. It is all relative and orthogonal as it maintains the version of file/directory and it's content.

Brad
Reply all
Reply to author
Forward
0 new messages