Re: [phpGroupWare-developers] Organising apps in svn

[Maât]

Dr. Christian Böttger a écrit :
> Maât schrieb:
>
>
> > For svn trees organisation this is only a question of keeping things 
> > "stupid simple"... and hiding communication about apps statuses  
> > inside the pathes of  svn repos will make phpgw even harder to get in 
> > that it is now i think.
>
> basically we have two independent sorting criteria here: core, 
> devtools, applications on one hand (regardless of status) and features 
> criteria like supported, orphaned, ... on the other. Perhaps even a 
> thrid, again indepented set like minimal setup, standrd, full, 
> <various flavors).
>
> Isn't that what tags etc are for?

definetely no  :)

tags in svn are not thought to deal with that.

tags in svn are symply code freeze points with a label

Mnemonic : think of svn tags as "versions"

> Moving around applications from one tree to another on status change 
> seems to be unnatural to any version control system. But having a 
> logical tag named "supported apps" or "phpGW taylored for <whatever>" 
> resulting in the checkout of all code in that status (core + apps) can 
> be a very handy feature.

i agree with the feature need of "checkout of all code in [a particular] 
status" and svn external links can be very helpful for that

you can have a specific "flavor" structure in svn using massively 
external links to apps specific tags so that a single checkout brings 
also the wanted apps (with the right version) with it and if you use 
tags on it you can have something very simple to use and easy to maintain.

But i stick with what i said : using svn organization to store statuses 
and using svn move to reflect statuses changes will make history rather 
painful to read and svn changes of structure need to play with svn 
switch (which can be rather time consuming)...

very very poor quality in this approach... i made this kind of errors 
with svn whan i started playing with it some years ago... i give here a 
feedback linked to my personal experience... but you can choose not to 
follow the advice :)

> It's not "hiding the information in the path name", it's more "putting 
> it in there additionally" - more communication.
>
> just my 2¢

sorry but i disagree

> Regards
>
> CB