Child pages
  • CVS, Bug Tracker, Line of Development for In-Portal in CVS, Open Source Server
Skip to end of metadata
Go to start of metadata

Imported From:

We have 4 main topics to discuss:


There are a MUST things for Open Source Software:

  • Provide for ALL users to be able to Checkout the project from CVS, but LIMIT Commits and Checkout of other projects. Quick sample - . This requires clean and well structured CVS structure so developers are NOT getting turned down by unnecessary complexity of dealing with development.
  • CVS Cop - to limit access and require Comments on COMMIT + other add-ons.
  • CVS Spam so all subscribed to Development users receive New commits as soon as they occur. Emails contain nicely put Diffs. We already utilizing this on current prod.
  • Other CVS tools (to integrate with Wiki and Bug Tracker) like CVS History, CVS Graph ( ) and so on.

Considered options: 

  • Create new CVS Repository for Open Source with In-Portal and all modules.
  • Migrate to SVN.
  • Propose yours!

Bug Tracker 

Main requirements for Open Source Community to simplify the development and increase the interest - We must be 100% transparent to the user. Visible activity in our Development is our key to success in Open Source Community.

Beside standard features like User and Project management, Reporting/updating and assigning bugs, sending emails.


  • Integration with Wiki and CVS when changes in CVS are saved in correct bug and vice versa.
  • Versioning for Multiple Lines of Development.
  • Auto Mass-mailing to all users in the project on any update.
  • Monitor Issue and Watch User.
  • Patch Viewer - gives you a nice, colorful view of any patch attached to a bug. It also integrates CVS. In particular, it makes code review much easier.

Considered Options: 

  • In-Business
  • Mantis
  • Bugzilla

Things that Bugzilla does better:

Your comments please. 

Open Source Server

We need to decide where do we setup the server or it's virtual host.


  1. Here are my considerations:

    1. CVS
    All tools (cop, spam, view etc.) are fine. The main problem is creating a
    separate repository and choosing the format.
    SVN is theoretically better than CVS, but we have no experience in working
    with it. Getting to know SVN will take very much time, which we don't have.
    So I suggest staying with CVS.

    We would need a separate repository to isolate the community from our
    internal projects for security reasons. Obviously, we would need the
    repository to by synchronized with our current one (since we use the
    core/kernel in all our projects). There are number of tools out there for
    synchronizing repositories. So we would need Valentin to do a research on
    these tools, choose one and setup a demo environment with two synchronized
    repositories so we can test it. And we would need to run community
    repository on our servers, since I doubt we could setup and manage reliable
    synchronization between our repository and publicly hosted one.

    2. Bug tracker
    My only consideration for Bugzilla is that it's written in Perl and not PHP,
    so it would be more complicated for us to customize it if need it for
    whatever reason. If something in PHP (Mantis?) is good enough I would
    recommend using it.

    3. Line of development
    I've talked to Alex about the development line. It looks good overall in
    theory, but everybody should understand that MERGE operations can't be
    automated. So, every merge operation is going to consume relatively large
    amount of time and is also a source of potential bugs/problems. As we
    currently don't have any automated testing suite this becomes even bigger
    problem. So, we should minimize the number of merges done and we absolutely
    can't support more than 2 development lines (bug-fixes and features) with
    current development resources.
    To keep it simple my suggestion is to take two-lines scheme and keep usage
    of bug-fixes branch to the absolute minimum (i.e. fix only critical bugs in
    that branch), while keeping working on the "RC" line and releasing actual
    release candidates. This way we may eliminate the need for constant merges
    or keep it to the absolute minimum

    4. If you mean CVS server - my answer is above: it should be OUR server,
    dedicated (for security reasons). If you mean general open-source project
    place, I would suggest sticking with Google (I think it's called Google
    Code). Sourceforge is in my opinion more complicated and targeted for
    unixheads, while google is more open for general public.


  2. Thank you Kostia - many valid points.

    I am going to recap and summarize on what we agreed:

    1. CVS
    We'll introduce NEW CVS Repository separate from the current CVS on
    Prod (LV) to hold In-Portal Open Source project and publicly available
    for ALL users to Checkout project and/or modules, but Commits are done
    by Trusted users.

    At the same time we need:

    a. Find the way Synchronize commits/changes done in Open Source CVS to
    Prod CVS. We need to research, test and make sure it works. Valentin
    this is where we need your expertise.

    b. We must provide CLEAN and CLEAR way for users to see In-Portal and
    modules files using VewCV or similar CVS browse tool.

    Example of the structure:

    -- admin_templates
    -- units
    -- themes
    -- [other module specific folders]

    -- units
    -- themes
    -- [other module specific folders]


    Kostya, this is what we'll have to ask you to look into. Note that In-
    Edit will become part of In-Portal (CORE) functionality as it was
    decided long time ago and will not be as a separate module. All
    migration points related to development will be discussed under "In-
    Portal Development Group" which will be created shortly.

    c. All other CVS add-ons will be introduced and enabled as soon as we
    have firm confirmation on A. from above.

    Bug Tracer

    We selecting Bugzilla as Open Source Bug/Issue Tracker keeping In-
    Business as Project & Business management system for Internal projects
    with future option for creating an integration between two.

    Valentin and Sash - we'll need to setup a test Bugzilla installation
    building in such way it so we can start using for Open Source without
    redoing. All add-ons like should be added as soon as other parts of
    puzzle are ready

    CVS/Wiki/Bugzilla integration -

    Line of Development

    We are all agreed that will be keeping NOT more than 2 lines of
    development at the same time:

    1. Bug fixes of current Release (ie.
    2. New Features (ie.

  3. 1) It will be nice if we doing install on dedicated server.

    2) As I know we have 2 free servers - Osaka and Frankfurt, and my time
    in next week - 1 or 2 days.

  4. Valentin,

    Actually, I was thinking about using Atlanta - it is a better server.

    I will enter a task in IB for it.

    I will also send a separate e-mail about R&D work.

  5. Kostia, please explain to Valentin where we need his expertise and
    help with researching things on CVS dev/open source synchronization.

    We clearly need to understand if this is the right direction with CVS
    server plan.


  6. Hi everyone,

    Some nice and well put by Redhat magazine article about SVN as a good
    alternative to CVS now days.

    Valentin thanks for finding and sharing it ;)

  7. Interesting article, and book mentioned ( is
    really useful. Especially part for CVS users and list of programs used to
    convert CVS to SVN, like What SVN
    supports, that CVS doesn't:
    1. read/write access on per-directory basis - we can store our company
    projects together with open source projects in same repository and open
    source users won't see projects and branches, that they aren't allowed to
    2. centralized revision numbers - you can address any commit transaction
    (directories and files) using it's number.
    3. revision control for directories.
    4. moving support for files and directories - move history along with
    files/directories that are moved.

    One more thing: there are CodeReview extension for MediaWiki, that works
    with SVN only and allows to nicely view each transaction files/directories
    (in web browser) and made code review, that will improve code quality. SVN
    versioning system also simplify merging.

    SVN also supports building combined modules, like k4_dev (Kostja, will know
    what I mean). But I prefer "svn copy" command over module usage.

    Alexander Obuhovich
    R&D Manager
    Intechnic Europe Ltd.
    Phone: +371 7804099
    Fax: +371 7804098

  8. As for start we can convert all repository to SVN and see how it will
    look like. Main priority here is to keep history of files and idea,
    that kernel code should be shared module between all projects, that
    will simplify merges.
  9. Yes, I do agree and look at this as:

    + Standard CVS features that already got used to with CVS
    + More Flexibility - support for NEW things that we never had with CVS and
    needs with Open Source
    + Short learning CURVE - very similar with CVS command line language. I
    already tried a few major operations and it's really simply
    + Even more integration options with Buglizza, Media Wiki and other online
    tools crucial for Open Source Community.

    - Need to fully/partially convert existing CVS repository to SVN

    In result we'll have - a cleaner, easier to use and more flexible

    Kostia, what is your opinion on CVS/SVN topic?

    Also, as far as I know Valentin already started to run first tests for
    converting from CVS to SVN, so we'll see how this works out.


    On Sun, 8 Feb 2009 23:55:04 +0200, "Alexander Obuhovich"

  10. No doubt that SVN is better than CVS. But the question is how many
    hours we should spend company-wide for switching from CVS to SVN?
    Consider the following:

    - converting current huge repositroy to SVN
    - redoing all scripts we use (, for
    Projects, and pre_release, release, rotate, update etc. for Software)
    - reconfiguring backup system for SVN
    - installing/configuring svn-client on every server we use

    For every workstation/programmer:
    - installing the tools on every-workstation to work with SVN
    - reading documentation on those tools
    - reconfiguring Zend
    - reconfiguring compare/merge tools
    - explaining how to use new tools/scripts
    - finding bugs and special cases for tools/scripts usage, fixing bugs,
    adding special cases
    - explaining how to use new tools/script, yes, second time

    For every project on every prod*number of developers, dev, live,
    mirror etc:
    - re-checkouting the project, so that local data stays
    - fixing bugs caused by re-checkout

    Do the math and think again!

  11. What if we were to keep CVS for current projects and use SVN for In-
    portal only?

    Alex can setup some sort of synchronization between the two (even if
    it is manual for now).

    If SVN is indeed much better, we will put in some time and eventually
    switch to it.

    I do have concenrs that the current CVS is a big mess.  Soone or later
    we do need to clean it up anyways.

    Sounds like a compromise?