Re: [ros-kernel] Cleanup

[Patrick M. <ox...@st...>]

On Thu, May 30, 2002 at 04:43:20AM +0200, Casper Hornstrup wrote:
> CVS is great...when compared to having no version control system. This
> does not mean it cannot be improved upon. Some features I would like to
> see in a version control system includes:
ok, let's compare subversion (aka. SVN, http://subversion.tigris.org) and
arch (www.regexps.com) against your wishes, both are free

>   * Atomicity and scalable. CVS uses many locks.
      - SVN+Arch: atomic commits - commit the whole set or nothing of it
                  revisions are per-change, not per-change-of-file
>   * Versioned directories, renames, and moves.
      - SVN: versioned source tree, renames and moved explicitely
             (svn cp, svn mv...)
      - Arch: same as SVN, but also supports file tags for renames and
              moves (ie. have "tag: some_unique_identifier" in the file
	      header and this file _is_ unique with no special attention
	      to be taken for the VCS)
>   * Able to do more offline. Eg. the diffs used for the last
>     update could be cached.
      - SVN+Arch: a complete original tree is present on the local box,
                  in .svn or {arch} which is used for diffs etc


>   * Easier repeated merging. A pain to do with CVS. You have to be very
>     careful.
        what exactly do you mean by this?

>   * Better handling of binary files.
        Arch takes care of this for sure, I think SVN does as well (dunno)

>   * Fewer conlicts. Some smart person could probably figure out how to
>     achieve this. 
        by using something more sensible than diff/patch? maybe - but I
        don't know such a thing (except for the sccs-format maybe)

>   * Extensible through plugins. To allow for greater customization.
      - SVN: can be configured for that
      - Arch: doesn't support it for a reason: a respository should work
              for everyone without having to care for client side extensions
	      (there is no real "server")

>   * Per module/directory/file access control.
        on module-boundaries: does even exist with CVS, needs server access
        the other things: why? either you want to give access to the source
                          or you don't

>   * Issue tracking system integration. Eg. if I commit a patch with a
>     log message containing the tags "@issue ros10 @status fixed", then
>     the issue tracking system would be notified that the issue with ID
>     "ros10" should have status "fixed".
      - SVN: I guess they'll do something like that (compare: 
             scarab.tigris.org which is a sibling-project)
      - Arch: again, I guess sth. like that will be done - this time it's
              called labnotes

>   * Delayed transactions. If I wanted to ensure that a project at least
>     compiles after a patch is committed, then the transaction could be
>     put in a delayed state and then an external program is run to apply
>     the patch and then try to compile the project. If the compile is
>     successful then the transaction can be committed. If not, then
>     transaction is rolled back. This could be used with a regression
>     framework too, thereby achieving a more stable code base.
        why can't you do this on your own box? 

>   * Able to exclude certain paths from a working copy. Eg. for this
>     particular working copy I only need /dir1 and /dir2 but not
>     /dir1/subdir1 so don't update them when I update the working copy.
      - that could work with CVS, but not with SVN or Arch as both of them
        always do versioning over the whole tree, not over single files

>   * Assign meta data to files and directories. Versioned of course.
      - SVN has full metadata support (ie. put any junk you want into it)
      - Arch supports filesystem metadata

>   * Symbolic links. Cross repository symlinks too. OSS projects tend to
>     depend on each other so why not have a symlink in a repository
>     pointing to a path in another projects repository? Then you would
>     only need one URL as the version control system could transparently
>     follow symlinks to the other repositories.
      - SVN+Arch: internal symlinks should be supported
      - Arch: as you can branch (with the ability to merge forth and back)
              over server boundaries (as strictly speaking there is no
	      "server") that can be done easily as long as the other project
	      is also arch-controlled

some further description to arch (eg. why I insist that there is no server):
arch is designed to work on a local directory as repository which is enhanced
by some "virtual file system"-library which maps normal access to ftp
transparently for that process. there are patches to map onto sftp, webdav
and rsync as well, iirc.
after creating a local repository, you can branch off a remote one and work
(with full versioning) in your local repo with the ability to merge new
patchsets from the original place to the new one and back.

so it's not as there aren't any free VCS except CVS, it's just that they're
quite new and not yet in the 1.0 stage...

sincerely,
 patrick mauritz
-- 
,------------------------------------------------------------------------.
>   In the Beginning there was nothing, which exploded - Yeah right...   <
|------------------------------------------------------------------------|
>       The Forthcoming OpenBIOS | www.freiburg.linux.de/openbios        <
`------------------------------------------------------------------------'
         Understanding yourself without understanding your enemy
                 only gives you half a chance of victory