Hi all,
and my sincere apologies for the long post...
After making significant progress on deploying Trac & SVN
to manage software development projects in my organization,
I am now facing several challenges to support non-trivial processes in
several projects.
Some background, in order to put things in context:
- We have many, unrelated, development projects,
each with its own SVN repository and Trac environment.
- All projects start their life in the main office, based on a closed LAN
(absolutely no option for network communication beyond the 4 walls
of the office).
I shall refer to the office server as "central".
- Some projects require one or more development phases performed
outside of the office network.
To this end, we set up small dev-sites (1-5 PCs) at the remote locations,
and have a dev-team working there.
These dev-sites are, again, in a closed LAN -- no communication
beyond our dedicated PCs.
I shall refer to the remote dev-sites as "offsite".
- Periodically, we synchronize central-->offsite and offsite-->central.
Synchronization is performed by transferring CDs between the sites.
I have managed to establish a procedure for SVN repository synchronization,
based on offsite working only under a dedicated branch, central not
touching that branch,
and transferring filtered dumps between the sites and merging trunk<-->branch.
A side-result of the procedure is that revision numbers are not
consistent between sites.
,
I would like to establish a similar procedure for synchronization of
Trac environments,
but it seems somewhat more complex.
Here are several sync-use-cases I came up with:
- wiki edits: shouldn't be too hard, based on existing wiki-merging ([1], [5]).
should also handle custom content, like tags from the TagsPlugin.
- wiki add/rename/delete: also manageable, I think.
- modifying a ticket that exists in both sites: also shouldn't be too hard,
based on merging tickets with common IDs ([2] and [3]).
- creation of new tickets in both sites:
- might cause 2 unrelated-tickets with same id, which shouldn't be merged.
- maybe if each offsite could have a sub-realm for tickets, e.g.
"ticket/offsite-1",
so new tickets created in central are sequential in 'ticket/N' realm,
and new tickets created in offsite-1 are sequential in 'ticket/offsite-1/N'.
(similar to the concept of MultiRepository, also mentioned in [4]).
- another approach would be to assign ranges to different sites (also in [4]).
- duplicated creation of tickets in both sites: can be solved by merging
tickets after synchronization (a-la [2]).
- references to changeset numbers from wiki & tickets:
since the numbering is not consistent between the sites,
the synchronization process should fix such references based on a
conversion map.
such a conversion map can be generated during the repository-sync procedure.
- references to tickets from changeset comments:
shouldn't be a problem if ticket IDs are not transformed during syncs.
- changes to: milestones, versions, components, priorities,
severities, reports, etc.
I don't see much complications here (I think [5] has support for it?).
I am posting all this to the mailing list(s) for several reasons:
- Receive references to possible existing solutions for such use-cases,
that I don't know about.
- Hear from the dev team about related features that might already
exist in core,
features that are planned some time soon, and features that are not planned
until alien technology is incorporated, so I can work on relevant patches.
- If I describe use-cases that have no solution in plugins / scripts /
present-or-future core, I'd like to identify them in order to open
relevant tickets and get feedback on possible solutions in order to
start working on plugins / scripts / patches.
Supporting the described workflow is very important for my organization,
and it seems that we will need to put in some development effort into this,
which we are willing to do.
But wherever possible, I would like our development efforts to be in sync
with the roadmap of the community, so we can contribute as much
as possible during this development.
Again - sorry for the long post,
and if you read up to here - thanks a lot!
[1] http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiOperations#Merge
[2] http://trac.edgewall.org/ticket/3006
[3] http://trac.edgewall.org/wiki/DistributedTrac
[4] http://trac.edgewall.org/wiki/TracSynchronize#Challengeswhichmaycomeup
[5] http://trac-hacks.org/wiki/TracMergeScript
Itamar O.
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
