> /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? Branches, in my
opinion, should be temporary code paths destined to
eventually merge with the main trunk, such as to add
new features, fix bugs, etc.
2. Does ICS v6 represent a completely different
code-base than ICS v5, or is it a natural progression
for it? 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
