[EMAIL PROTECTED] wrote: >> /icsv(n) >> |-branches >> | |-ics-ssl >> |-tags >> | |-ics-ssl >> | | |- beta(n) >> | |-ics >> | |- release(n) >> |-trunk >> |-ics > > There's a few questions I have with your suggested > structure: > > 1. Is ICS-SSL really a branch of ICS, or should it be > considered a separate project?
It's no separate project. It shares most of the files with common ICS, most of the SSL code is available as .inc files compiled in conditionally. And it has its own demo-folder. > Branches, in my > opinion, should be temporary code paths destined to > eventually merge with the main trunk, Basically that's true, however think of it as a persistent branch, you can change everything however ever only merge those changes to the main trunk effecting the shared files. People can work with either common ICS or SSL and commit their changes. Merging with the branch or the other way around was very easy (allowed to admin users only). But I just read Francois reply, so this discussion is useless in any case. > > 2. Does ICS v6 represent a completely different > code-base than ICS v5, or is it a natural progression > for it? It's the latter, however the point when V6 has been split from the common base is already some years back and hard to restore. There will be no new features in V5 so merging between V5 and V6 is most likely not required. Also revision numbers are incremented for the entire project/repository. But I could very well live with both in the same repository as well, locally I also treat them as two different projects. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > If the former, then they indeed should be > separte projects. But if the latter, they should > form part of the same code base: If ICS v5 is > currently the "stable" version, and ICS v6 represents > a new version that will eventually supplant it, then > I suggest ICS v5 represent the main trunk, and ICS v6 > become a branch of it. Once ICS v6 matures and > replaces v5, it will be merged into the main trunk, > and v5 set as a Tag. But if v6 represents the > version where most development will be done, and v5 > is only for legacy support, then it should be the > other way around. > > Also, keep in mind that merging is done locally in > the user's working directory, not directly in the > repository. > To merge, you select a source path from > the repository, and specify which revisions to > include; SVN will then merge those changes with your > working directory (representing the target repository > path). Once all conflicts are resolved, the updated > (merged) working directory can be commited by the user. > > Therefore, it is possible for users to revert > accidentally changes commited previously, by > commiting "wrongly" merged files. The good thing is > that the changes were not lost (they are still in the > repository history), and can easily be returned. > > By "wrongly merged files", I mean that the user > mistakenly overwrote other's changes with his own or > with an older version of code. This is the scenario > that I alluded to before, and it is fairly common > among people who are not used to version control systems. > > -dZ. > > > >> ------- Original Message ------- >>> From : Arno Garrels[mailto:[EMAIL PROTECTED] >> Sent : 10/8/2007 1:03:09 PM >> To : twsocket@elists.org >> Cc : >> Subject : RE: Re: [twsocket] Using SourceForge for ICS ? >> > >DZ-Jay wrote: >> On Oct 7, 2007, at 14:57, Arno Garrels wrote: >> >>> Isn't it safe to use the Copy-Modify-Merge solution, described in >>> the online-help ? >> >> Yes, it is very safe. > > Now that I checked how to merge particular changes > made in > branches to the main source tree under trunk I would like > to suggest the following, same structure for two > different > repositories one for V5 and one for V6: > > /icsv(n) > |-branches > | |-ics-ssl > |-tags > | |-ics-ssl > | | |- beta(n) > | |-ics > | |- release(n) > |-trunk > |-ics > > Where the ics-ssl branch and tags cannot be accessed by > common ics users. AFAIK it is only possible to merge > between common and SSL when the SSL code is in the same > repository, is that true? It works very well and makes it > very easy to maintain. If Francois does not want to > put the > SSL code into the project/repository as well ? I think we > won't safe very much. What do you think? > > -- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > > > -- > To unsubscribe or change your settings for TWSocket > mailing list > please goto > http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
