[linux-dvb] Re: [OT] subversion [Was: Re: wiki?]

[Wolfgang Fritz <wolfgang.fritz@gmx.net>]

Holger Waechtler wrote:
> Klaus Schmidinger wrote:
> 
>>Tomi Ollila wrote:
>>
>>
>>>Tuesday Sep 7 18:30:42 +0200 2004 Holger Waechtler <holger@qanu.de> wrote:
>>>
>>>
>>>>Hi all,
>>>>
>>>>as you probably all know the linuxtv.org websites are quite out of date
>>>>and almost nobody of the developers is really willing to keep them
>>>>up-to-date. So I'd like to open a discussion how this situation may get
>>>>improved.
>>>>
>>>>May/should we try to use a wiki instead of the static webpages? This
>>>>would at least make it easier to keep the supported-cards list and the
>>>>DVB application link page more up-to-date. If so, which wiki
>>>>implementation should we prefer? Is anybody of you experienced with
>>>>this, are there any preferences we should consider?
>>>>
>>>>Another approach would be to import the web pages into the CVS
>>>>repository, then at least all developers with CVS accounts could edit
>>>>the html/xml pages.
>>>>
>>>>what do you think?
>>>
>>>Convert CVS repository to subversion
>>
>>
>>Please don't!
> 
> 
> can you please elaborate your concerns a little more in detail?
>

Hi,

my company is in the process to switch to a unified company wide
versioning tool and has decided to use subversion. I, who is using CVS
for years, am trying at the moment to get familiar with subversion. My
impressions up to now:

Good:

- Atomic commits. If you check in a couple of files in one commit, it is
guaranteed that all changes go in or none if you interrupt the commit.
The commit gets one revision number and it is easy to identify all
changes belonging to that commit later. No need for tagging here. Other
commits started by others at the same time do not interfere with your
commit (in the sense of versioning).

- Simple file copy and move with history.

- Directory operations (copy, move) and versioning.

- Global version numbers. Version numbers belong to a commit, not to a file.

- Improved offline working. You can diff your working copy against your
last updated version without accessing the repository.

- Diffed commits. Commits are sent as diffs. This is a an advantage if
the repositiory has to be accessed via a slow net connection.

Bad:

- Branching and tagging. Conceptual, there are no branches and tags in
subversion. You have to emulate them by copy operations.

- Tracking of vendor trees. This is quite easy in CVS but must be
enulated in subversion in a similar way as branches and tags.

- Bad graphical frontends at least for Linux. I love tkcvs. There is no
functional equivalent graphical frontend for subversion up to now. This
may change in the future.

- Stability. I got the impression while reading the subversion ML that
subversion is not completely stable right now. This is a personal
impression of course, and may be wrong. At least the subversion
developers are eating their own food and using it for their projects.

Wolfgang

> Holger
> 
>