[OT] Rant about VCS

[OT] Rant about VCS

[Alex Baretta]

Please forgive me for ranting about source code Version Control Systems 
on the list, but I can't help it. Besides, I would like to know what the 
gurus on the list use to manage their own projects.

My company handles close to 100kloc of Ocaml and ocaml related files 
under CVS. We have gotten sick and tired of having to reconstruct CVS 
repositories from scratch every once in a while because we need to move 
files or delete directories.

It appeared to us that Darcs might solve the problem: it seems based on 
a reasonably sound algebraic model and is written in Haskell, which 
supposedly should be a bonus compared to other VCSs written in C.

Yet, darcs lacks some of the most basic features of a VCS, such as 
handling metadata (the executable bit, essentially). The darcs 
developers say that this is a "planned feature" but nothing really 
urgent. Actually, we think this is a critical feature in a big project 
which relies on scripts and other executables distributed together with 
the source for bootstrapping purposes. Ocaml itself ships with a full 
compiler to be able to bootstrap, albeit this does not depend on the 
executable bit being set anywhere since ocamlrun is generated by the C 
compiler.

Other VCSs such as subversion seem to be so unstable as to severely 
discourage their use in an industrial project.

***

What is the Ocaml way to solve this problem? What VCS do caml breeders 
and riders use?

I definitely hope I must not write YAVCS in Ocaml...

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] [OT] Rant about VCS

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 17, 2004, at 9:07 AM, Alex Baretta wrote:

> It appeared to us that Darcs might solve the problem: it seems based 
> on a reasonably sound algebraic model and is written in Haskell, which 
> supposedly should be a bonus compared to other VCSs written in C.
>
> Yet, darcs lacks some of the most basic features of a VCS, such as 
> handling metadata (the executable bit, essentially). The darcs 
> developers say that this is a "planned feature" but nothing really 
> urgent. Actually, we think this is a critical feature in a big project 
> which relies on scripts and other executables distributed together 
> with the source for bootstrapping purposes. Ocaml itself ships with a 
> full compiler to be able to bootstrap, albeit this does not depend on 
> the executable bit being set anywhere since ocamlrun is generated by 
> the C compiler.
>
> Other VCSs such as subversion seem to be so unstable as to severely 
> discourage their use in an industrial project.
>
darcs is a great tool. 1.0.1 was just released. For your purposes 
you'll be interested in the "setprefs test" sub-command, which allows 
you to define a process to execute before some darcs commands--see the 
docs for details.

I use EMACS and Tuareg Mode for my O'Caml programming, so I also use 
darcsum.el to integrate EMACS and darcs. I find this quite nice.

If all of this is too much, consider GNU Arch in its tla incarnation, 
which does version file flags on POSIX filesystems, and also has very 
good EMACS integration in the form of XTLA.

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iEYEARECAAYFAkHDKLYACgkQbot1wzHBQBVAMgCbB2MTet7XB4AOzd9eyqdIT7Mj
KO0An2ClbNs7G/ZkS7Hp7RXHKBje99gp
=nrMe
-----END PGP SIGNATURE-----

Re: [Caml-list] [OT] Rant about VCS

[Yaron Minsky]

We use Arch here for several projects, totaling about 100kloc.  Arch
works pretty well and reliably.  It's got a bit of a learning curve,
and the usability of the command line tool is pretty horrific.  Still,
it's underlying design is very good, and it gets the job done.

Yaron

On Fri, 17 Dec 2004 10:42:51 -0800, Paul Snively <psnively@mac.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Dec 17, 2004, at 9:07 AM, Alex Baretta wrote:
> 
> > It appeared to us that Darcs might solve the problem: it seems based
> > on a reasonably sound algebraic model and is written in Haskell, which
> > supposedly should be a bonus compared to other VCSs written in C.
> >
> > Yet, darcs lacks some of the most basic features of a VCS, such as
> > handling metadata (the executable bit, essentially). The darcs
> > developers say that this is a "planned feature" but nothing really
> > urgent. Actually, we think this is a critical feature in a big project
> > which relies on scripts and other executables distributed together
> > with the source for bootstrapping purposes. Ocaml itself ships with a
> > full compiler to be able to bootstrap, albeit this does not depend on
> > the executable bit being set anywhere since ocamlrun is generated by
> > the C compiler.
> >
> > Other VCSs such as subversion seem to be so unstable as to severely
> > discourage their use in an industrial project.
> >
> darcs is a great tool. 1.0.1 was just released. For your purposes
> you'll be interested in the "setprefs test" sub-command, which allows
> you to define a process to execute before some darcs commands--see the
> docs for details.
> 
> I use EMACS and Tuareg Mode for my O'Caml programming, so I also use
> darcsum.el to integrate EMACS and darcs. I find this quite nice.
> 
> If all of this is too much, consider GNU Arch in its tla incarnation,
> which does version file flags on POSIX filesystems, and also has very
> good EMACS integration in the form of XTLA.
> 
> Best regards,
> Paul Snively
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (Darwin)
> 
> iEYEARECAAYFAkHDKLYACgkQbot1wzHBQBVAMgCbB2MTet7XB4AOzd9eyqdIT7Mj
> KO0An2ClbNs7G/ZkS7Hp7RXHKBje99gp
> =nrMe
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] [OT] Rant about VCS

[Erik de Castro Lopo]

On Fri, 17 Dec 2004 10:42:51 -0800
Paul Snively <psnively@mac.com> wrote:

> If all of this is too much, consider GNU Arch in its tla incarnation, 
> which does version file flags on POSIX filesystems, and also has very 
> good EMACS integration in the form of XTLA.

I'm using GNU Arch for large amounts of C, C++, Python, Ocmal, plain 
text and LateX.

I think Arch is the best thing since sliced bread. The ony problem is
it doesn't like ms windows. It stores files in a really deep directory
structure and its really easy to run into the limit of how long
a pathname can be on windows.

If you are Unix only Arch is well worth a look. Its a bit difficult
to set up and get the hang of, but if you are not on windows, its
well worth it.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"No Silicon Heaven?  Preposterous!  Where would
all the calculators go?" -- Kryten, Red Dwarf

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Fri, Dec 17, 2004 at 06:07:54PM +0100, Alex Baretta wrote:
> Please forgive me for ranting about source code Version Control Systems 
> on the list, but I can't help it. Besides, I would like to know what the 
> gurus on the list use to manage their own projects.
> 
> My company handles close to 100kloc of Ocaml and ocaml related files 
> under CVS. We have gotten sick and tired of having to reconstruct CVS 
> repositories from scratch every once in a while because we need to move 
> files or delete directories.
> 
> It appeared to us that Darcs might solve the problem: it seems based on 
> a reasonably sound algebraic model and is written in Haskell, which 
> supposedly should be a bonus compared to other VCSs written in C.

...

> What is the Ocaml way to solve this problem? What VCS do caml breeders 
> and riders use?

We have had good success with subversion, which has the added advantage of
being very very user friendly, and an almost immediate proficiency in it if
one has CVS knowledge. We are using it for the debian/ocaml package repository
(not upstream source, just the packages and the debian dir), and also for
larger projects, like the new debian-installer source repository, and the new
debian kernel packages (altough we don't keep the whole kernel source tree
there, just the debian patches).

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Erik de Castro Lopo]

On Fri, 17 Dec 2004 22:37:53 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> We have had good success with subversion, 

I looked at subversion before deciding on Arch. The main downside
I saw to subversion was that merging across branches was as painful
as wil CVS. Arch on the other hand has two powerful merging 
methods and there is a thrid one on the way. This allows me to
run a couple of parallel developement branches, share those that
need to be with other external developers and merge acorss the
branches pretty much at will. 

I have not seen another source contol system which handles
branches as nicely as Arch.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"When your hammer is C++, everything begins to look like a thumb."
-- Steve Haflich, in comp.lang.c++

Re: [Caml-list] [OT] Rant about VCS

[skaller]

On Sat, 2004-12-18 at 04:07, Alex Baretta wrote:
> Please forgive me for ranting about source code Version Control Systems 
> on the list, but I can't help it. Besides, I would like to know what the 
> gurus on the list use to manage their own projects.

Well, I solve the build complexities using interscript.

The principle packaging concept is a simple set of
subpackages, each of which is a plain text file.

One file is the main one. It is processed like

	iscr main.pak

This command builds the actual distribution file set.

Moving files around, adapting them for the platform,
etc, are all handled *within* this system.

For example I use Cil -- this is packaged up as two
files: flx_frontc.ipk and flx_cil.ipk (Cil is built
on top of frontc).

Most of my build scripts are packaged in flx_maker.ipk.
I have several sets of tests, eg: flx_tutorial.ipk
is the tutorial (which is also a test suite).

Using any version control system to manage detail
level files is really archaic. Interscript is a much
better solution.

Wc on my LP archive shows:

  93781  374389 2674323 total

which is 2 1/2 meg of pure source code, 370Kloc,
in 89 files. Of course the actual 'source' code is bigger,
since some is generated.

The package includes

(0) Interscript -- python tree containing the extract tool
(a) Felix (ocaml + C++)
(b) OCS scheme (ocaml) -- ONE file
(c) FISh 1.6 (Ocaml)  -- ONE file
(d) Frontc (Ocaml) -- ONE file
(e) CIL (Ocaml) -- ONE file
(f) Elkhound (C++) -- THREE files

and coming: 

(g) Lua


Now it happens that I am using CVS on Sourceforge.
On my network link this is a PAIN it is so slow.

But whilst there may still be a need to 'move directories'
around etc, I haven't run into it yet. When I reorganise
the 'source' code that reorganisation is entirely built
into the internal interscript LP structure -- CVS never
sees it. At worst I occasionally delete a file or add
a file.

Although originally designed as a Literate Programming tool,
I am not really using interscript for that much: I'm using
it as an advanced package manager instead. Just simple
things like this:

@h = tangler("src/flx_xxx.ml")
@select(h)
let f x = x
....

@h = tangler("src/flx_xxx.mli")
@select(h)
val f:int -> int
....

which allows you to group files is a major bonus.
The other is: lines starting with @ are arbitrary
Python script. For example:

...
@keywords = ['fred','joe']
@for i in keywords: tangle('(' + str i +',"' + str i+'")')
@# generates a nice table of pairs (fred,"fred") etc

This is *infintely* superior to rubbish like template files
which some script fills in (eg autoconf style rubbish):
it is universally available and arbitrary code can generate
any part of any file in any way -- code generation
is *local* not external.

You could probably implement your own tool to do this,
say in Scheme instead of Python: all you really need 
to do it is 'eval'.

The downside is: you MUST not edit 'source' code.
Instead you edit the source generators, which implies
after every change you have to re-extract your source tree.
[Interscript is smart, and only re-extracts changed subtrees]

This also means no syntax colouring or building inside
emacs (unless you extend it to handle the tool).

The upside is -- recent change to Elkhound, Scott used
'string' as a class name which isn't nice -- fixed
with 6 global search and replace in Vim. (3 files,
2 changes since '#include "string.h"' was screwed up
by the first replace). That is, systematic editing
is easier because all the related 'files' are in one file.

Also does nice things like copy '*.mli' files to '*.ml'
files when they're the same file .. etc etc.

To really understand how all this works, you could
just try it :)

http://felix.sf.net/download.html

You'll note even though I have a Python maker script,
I still generate a conventional Makefile and use
it to do the top level making, and also to bootstrap
the build process (the Makefile you get out of the
tarball is immediately clobbered by a generated one).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 09:27:16AM +1100, Erik de Castro Lopo wrote:
> On Fri, 17 Dec 2004 22:37:53 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> > We have had good success with subversion, 
> 
> I looked at subversion before deciding on Arch. The main downside
> I saw to subversion was that merging across branches was as painful
> as wil CVS. Arch on the other hand has two powerful merging 
> methods and there is a thrid one on the way. This allows me to
> run a couple of parallel developement branches, share those that
> need to be with other external developers and merge acorss the
> branches pretty much at will. 
> 
> I have not seen another source contol system which handles
> branches as nicely as Arch.

Well, arch and subversion are different kind of system. subversion is a good
cvs replacement, while arch aims more at the bitkeeper category. I tried to
setup an arch repo for the parted project almost a year ago, and utterly
failed, since it was so complex to setup, and needed some kind of black magic
knowledge and hand intervention to setup right, but then this has hopefully
been fixed since then. That said, there is no real support for tagging in
arch, which is what makes subversion preferable for the debian-like usage,
where we tag each released version. The fact that each tag is indeed a branch
in subversion may be confusing though, and imposes some dicipline on the user.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Erik de Castro Lopo]

On Sat, 18 Dec 2004 10:28:56 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> Well, arch and subversion are different kind of system. subversion is a good
> cvs replacement, while arch aims more at the bitkeeper category.

Yes, subversion aims to be a better CVS while Arch and Bitkeeper
aim to be a better revision control system. If you want a better
revision control system CVS is probably not a good place to
start.

> That said, there is no real support for tagging in
> arch, which is what makes subversion preferable for the debian-like usage,
> where we tag each released version.

There is an arch way to do this:

    tla tag project--devel project--release--versionnumber

Its even called tag. What more could you want :-).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"There is no satisfactory substitute for excellence."
-- Dr. Arnold O. Beckman

Re: [Caml-list] [OT] Rant about VCS

[Erik de Castro Lopo]

On Sat, 18 Dec 2004 10:28:56 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> That said, there is no real support for tagging in
> arch, which is what makes subversion preferable for the debian-like usage,
> where we tag each released version.

BTW, of the three debian developers I know, all three use Arch
to track their Debain projects.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The power of accurate observation is commonly called cynicism by those
who don't have it." -- George Bernard Shaw

Re: [Caml-list] [OT] Rant about VCS

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

If you're finding Arch too hard, have a look at Darcs.  This page
describes how to create a repository:

http://abridgegame.org/darcs/manual/node4.html

Rich.

-- 
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://execellence.co.uk/ - Interim and executive recruitment

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] [OT] Rant about VCS

[henri dubois-ferriere]

> Other VCSs such as subversion seem to be so unstable as to severely
> discourage their use in an industrial project.

never used it myself, but i've heard lots of positive things from
people using subversion lately, in particular that it is reliable and
stable.
[to the point i'm finally considering switching over from cvs]

can you elaborate on the instability of subversion?

tx
henri

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 08:52:05PM +1100, Erik de Castro Lopo wrote:
> On Sat, 18 Dec 2004 10:28:56 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> > That said, there is no real support for tagging in
> > arch, which is what makes subversion preferable for the debian-like usage,
> > where we tag each released version.
> 
> BTW, of the three debian developers I know, all three use Arch
> to track their Debain projects.

Well, sure, which is the difference between individual developpers, and large
cooperative setups. Debian-installer being the biggest of such, and it uses
subversion. But hey, you chose what you want, i am only saying that arch's
syntax is somewhat obscure, while there is almost no barrier to entry for
subversion.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 08:49:15PM +1100, Erik de Castro Lopo wrote:
> On Sat, 18 Dec 2004 10:28:56 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> > Well, arch and subversion are different kind of system. subversion is a good
> > cvs replacement, while arch aims more at the bitkeeper category.
> 
> Yes, subversion aims to be a better CVS while Arch and Bitkeeper
> aim to be a better revision control system. If you want a better
> revision control system CVS is probably not a good place to
> start.
> 
> > That said, there is no real support for tagging in
> > arch, which is what makes subversion preferable for the debian-like usage,
> > where we tag each released version.
> 
> There is an arch way to do this:
> 
>     tla tag project--devel project--release--versionnumber
> 
> Its even called tag. What more could you want :-).

I was told that to do what i wanted to do, you would need to use arch's
configs or whatever they where named, and that the tag stuff was not really
upto it. I don't remember the details, it was aroudn january or so.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 11:24:00AM +0000, Richard Jones wrote:
> If you're finding Arch too hard, have a look at Darcs.  This page
> describes how to create a repository:
> 
> http://abridgegame.org/darcs/manual/node4.html

Seems interesting. I wonder if there is a bitkeeper to darcs gateway, that
would make it perfect for kernel work.

I wonder about the wisdom of naming the commit record instead of commit
though.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 12:25:31PM +0100, henri dubois-ferriere wrote:
> > Other VCSs such as subversion seem to be so unstable as to severely
> > discourage their use in an industrial project.
> 
> never used it myself, but i've heard lots of positive things from
> people using subversion lately, in particular that it is reliable and
> stable.
> [to the point i'm finally considering switching over from cvs]
> 
> can you elaborate on the instability of subversion?

Well, most of the alternatives used to not be very stable a year or two ago.
There are some troubles in subversions web interface (i think debian used
webcvs or something such), which had the bad habit of locking the database,
but apart from that it is pretty stable, especially since the 1.0 version was
released.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Richard W.M. Jones]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

On Sat, Dec 18, 2004 at 04:01:51PM +0100, Sven Luther wrote:
> On Sat, Dec 18, 2004 at 11:24:00AM +0000, Richard Jones wrote:
> > If you're finding Arch too hard, have a look at Darcs.  This page
> > describes how to create a repository:
> > 
> > http://abridgegame.org/darcs/manual/node4.html
> 
> Seems interesting. I wonder if there is a bitkeeper to darcs gateway, that
> would make it perfect for kernel work.

There's a Darcs mirror of the Linux kernel, but I don't think it
includes versions (ie. it's not a true export from BitKeeper).

http://darcs.net/linux.html

The problem that Darcs has on repositories of this size is that to do
its branching and merging magic, it needs to hold the whole codebase
in memory at once.  With the size of the Linux kernel, this reportedly
requires about 300MB of real RAM and up to 700MB of virtual memory.
[Source: http://lwn.net/Articles/110427/]

Rich.

-- 
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://winwinsales.co.uk/ - CRM consultancy

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] [OT] Rant about VCS

[Richard W.M. Jones]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Sat, Dec 18, 2004 at 03:22:44PM +0000, Richard W.M. Jones wrote:
> There's a Darcs mirror of the Linux kernel, but I don't think it
> includes versions (ie. it's not a true export from BitKeeper).

Apologies - I should read my own web page.  It's an export from
BitKeeper, via CVS, and thus will have some shortcomings, but should
include some version info.

Rich.

-- 
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://winwinsales.co.uk/ - CRM consultancy

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] [OT] Rant about VCS

[Sven Luther]

On Sat, Dec 18, 2004 at 03:22:44PM +0000, Richard W.M. Jones wrote:
> On Sat, Dec 18, 2004 at 04:01:51PM +0100, Sven Luther wrote:
> > On Sat, Dec 18, 2004 at 11:24:00AM +0000, Richard Jones wrote:
> > > If you're finding Arch too hard, have a look at Darcs.  This page
> > > describes how to create a repository:
> > > 
> > > http://abridgegame.org/darcs/manual/node4.html
> > 
> > Seems interesting. I wonder if there is a bitkeeper to darcs gateway, that
> > would make it perfect for kernel work.
> 
> There's a Darcs mirror of the Linux kernel, but I don't think it
> includes versions (ie. it's not a true export from BitKeeper).
> 
> http://darcs.net/linux.html
> 
> The problem that Darcs has on repositories of this size is that to do
> its branching and merging magic, it needs to hold the whole codebase
> in memory at once.  With the size of the Linux kernel, this reportedly
> requires about 300MB of real RAM and up to 700MB of virtual memory.
> [Source: http://lwn.net/Articles/110427/]

Main problem seems to be :

 The repository is converted from the bkcvs mirror, and is updated once a day.
 As a result, it doesn't contain any information about file renames.

Seems like a shame to me to go through CVS here, since you loose one of the
important features. And well, what we really need is to get access to any
arbitrary kernel bk trees, not only whichever one was used here.

Friendly,

Sven Luther

Re: [Caml-list] [OT] Rant about VCS

[Erik de Castro Lopo]

On Sat, 18 Dec 2004 15:45:58 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> I was told that to do what i wanted to do, you would need to use arch's
> configs or whatever they where named,

I've never needed the config stuff so I haven't looked into it.

> and that the tag stuff was not really
> upto it. I don't remember the details, it was aroudn january or so.

Tag was working perfectly when I started using Arch in October of
2003.


Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The growing and dangerous intrusion of this new technology,
threatens an entire industry's economic vitality and future
security." -- Jack Valenti (MPAA president) on the video
cassette recorder, 1982.

Re: [Caml-list] [OT] Rant about VCS: Conclusions

[Alex Baretta]

Erik de Castro Lopo wrote:
> On Fri, 17 Dec 2004 22:37:53 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> 
>>We have had good success with subversion, 
> 
> 
> I looked at subversion before deciding on Arch. ...  This allows me to
> run a couple of parallel developement branches, share those that
> need to be with other external developers and merge acorss the
> branches pretty much at will. 
> 
> I have not seen another source contol system which handles
> branches as nicely as Arch.
> 
> Erik

Paul Snively wrote:
 > It really does sound as though you're edging from "version control"
 > into "configuration management." If that's the case, you may want to
 > look at Arch and its surrounding tools. In particular, the
 > documentation at
 > <http://www.gnu.org/software/gnu-arch/tutorial/multi-tree-
 > projects.html>, "Multi-tree Projects and Configuration Management,"
 > might be helpful to you.

There seems to be some agreement on the fact the "Configuration 
Management Tool of Choice for Discriminating Software Company" is Arch. 
Our project seems complicated enough to seriously consider moving to arch.

We have currently reimplemented our project's storage as a 
non-denumerable set of darcs repositories, distributed in a 
discontinuous manner over our company's network. I envision a 
significant risk of complexity explosion, because darcs only supports 
branches as duplicate repositories, which sounds like a nightmare. 
However, darcs is about as much as would fit in before Christmas. Maybe 
Santa Claus will put a working arch repository under my Christmas tree...

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] [OT] Rant about VCS: Conclusions

[Blair Zajac]

Alex Baretta wrote:
> Erik de Castro Lopo wrote:
> 
>> On Fri, 17 Dec 2004 22:37:53 +0100
>> Sven Luther <sven.luther@wanadoo.fr> wrote:
>>
>>
>>> We have had good success with subversion, 
>>
>>
>>
>> I looked at subversion before deciding on Arch. ...  This allows me to
>> run a couple of parallel developement branches, share those that
>> need to be with other external developers and merge acorss the
>> branches pretty much at will.
>> I have not seen another source contol system which handles
>> branches as nicely as Arch.
>>
>> Erik
> 
> 
> Paul Snively wrote:
>  > It really does sound as though you're edging from "version control"
>  > into "configuration management." If that's the case, you may want to
>  > look at Arch and its surrounding tools. In particular, the
>  > documentation at
>  > <http://www.gnu.org/software/gnu-arch/tutorial/multi-tree-
>  > projects.html>, "Multi-tree Projects and Configuration Management,"
>  > might be helpful to you.
> 
> There seems to be some agreement on the fact the "Configuration 
> Management Tool of Choice for Discriminating Software Company" is Arch. 
> Our project seems complicated enough to seriously consider moving to arch.
> 
> We have currently reimplemented our project's storage as a 
> non-denumerable set of darcs repositories, distributed in a 
> discontinuous manner over our company's network. I envision a 
> significant risk of complexity explosion, because darcs only supports 
> branches as duplicate repositories, which sounds like a nightmare. 
> However, darcs is about as much as would fit in before Christmas. Maybe 
> Santa Claus will put a working arch repository under my Christmas tree...
> 
> Alex

Alex,

Coming into this thread a little late and being somebody who has commit 
rights to the Subversion source code, I'll try to make a couple unbiased 
comments on some of the statements made in this thread :)

The Subversion code is stable and production ready.  There were issues 
with the initial versions of Subversion and I had my share of locked 
repositories, but probably like early versions of every version control 
system, they have been resolved.  Also, the Subversion team eats their 
own dog food.

At this "Discriminating Software Company", we moved from CVS to 
Subversion one year ago and our Subversion repositories now contain 5.4 
Gbytes of code, documentation, Squeak binaries, PDFs, etc.  We haven't 
lost any data.

 From a company's point of view, other things you get that I don't 
believe the other mentioned open-source VCS' have are professional 
support and native Windows clients.  In our team, we have people 
creating documentation (Word documents, PDFs) for the code we write and 
we use TortoiseSVN, a Windows Explorer shell integration which makes it 
easy for non-coders to use a VCS while keeping a familiar interface, in 
this case just Windows itself.

Regarding merging, unlike CVS, Subversion has changesets, so merging is 
simply picking the changeset(s) you want from one path and applying it 
to another:

     % svn merge -r 2345:2347 branch/latest_changes branch/stable

You may want to check these URLs and I'll leave the propaganda at that :)

http://subversion.tigris.org/propaganda.html
http://www.red-bean.com/sussman/svn-anti-fud.html
http://tortoisesvn.tigris.org/

Regards,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Caml-list] [OT] Rant about VCS: Conclusions

[Erik de Castro Lopo]

On Tue, 21 Dec 2004 14:03:30 -0800
Blair Zajac <blair@orcaware.com> wrote:

> Regarding merging, unlike CVS, Subversion has changesets, so merging is 
> simply picking the changeset(s) you want from one path and applying it 
> to another:

Ahh, now I remember the problem subversion has with merging across 
branches with respect to Arch.

Please correct me if I am wrong, but from what I have heard, 
subversion is not able to recognise if a changeset has already
been applied or not and trying to apply a changeset which has
already been applied can lead to merge conflicts which need 
manual intervention to correct.

Arch OTOH keeps a log of all changesets applied to a tree. That 
means that if you have three branches A, B and C, all with the same
common ancestor you can merge A -> B and then B -> C. Now if you
try to merge A -> C Arch is clever enough to figure out which
changesets in A have already been applied to C and which ones 
haven't, and then only apply the ones that have not been applied.


Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
I have found that good programmers either do not make the kind
of mistakes that Ada can prevent, or insert enough checks that
they catch those mistakes about as efficiently as an Ada
environment can. At that point, the use of Ada gives no further
productivity advantage.

Re: [Caml-list] [OT] Rant about VCS: Conclusions

[David Brown]

On Wed, Dec 22, 2004 at 09:36:27AM +1100, Erik de Castro Lopo wrote:

> Arch OTOH keeps a log of all changesets applied to a tree. That 
> means that if you have three branches A, B and C, all with the same
> common ancestor you can merge A -> B and then B -> C. Now if you
> try to merge A -> C Arch is clever enough to figure out which
> changesets in A have already been applied to C and which ones 
> haven't, and then only apply the ones that have not been applied.

As far as I know, Arch and darcs are the only reasonably popular SCMs that
keep track of merge history sufficiently.  (I know nothing about BK, since
I'm not allowed to run it, it probably does track this correctly).  PRCS
was probably the first to popularize this level of tracking of changes.

It is a deeper issue than just knowing which changes to apply.  When you
have two active branches where changes propagate between them (common when
there are two active branches), a solution other than Arch, or darcs
quickly becomes unmanageable.  The solution with most other SCMs is to just
not do this, but it is a realistic scenario, especially when there are
specific "customers" for specific releases.

Darcs and Arch take very different approaches.  Arch approaches this from a
'patch' model, where it tries to find a common ancestor, and apply the
appropriate patches to this ancestor, allowing the patch program to try and
deal with the differences.

Darcs, instead, has the ability to mutate the patches themselves to be
applicable in different contexts.  It has the advantage of being completely
deterministic as far as conflict resolution.  It also has the problem that
in some instances, it just gives up, declaring that a patch cannot be
applied, rather than trying to do so and letting and edit of the conflict
take place.

The implementors Arch and Darcs seem to understand the complexity and
difficulty of cross branch merging, and embrace it head on.  Other
solutions tend to brush off the problem as not important, and generally
leave the user with some very tricky merge cases.

Perforce (commercial) attempts to track merge history, but does a terrible
job of it.

Aegis does seem to track merges well, although it can be obscure figuring
out what commands are needed to apply the merges.  I've also had problems
where it applied the merge correctly, and them completely undid the change
when 'resolving' the conflicts.

Dave

Re: [Caml-list] [OT] Rant about VCS: Conclusions

[Erik de Castro Lopo]

On Tue, 21 Dec 2004 15:19:40 -0800
David Brown <caml-list@davidb.org> wrote:

> The implementors Arch and Darcs seem to understand the complexity and
> difficulty of cross branch merging, and embrace it head on.  Other
> solutions tend to brush off the problem as not important, and generally
> leave the user with some very tricky merge cases.

Yes indeed. The funny thing is that when you get a system that does know
how to handle all this, you get new ways of working that simply aren't
possible with more archaic systems.

For instance, the most common usage of Arch with two geographically 
remote developers has developer A set up an initial public archive on 
a web server WA. The second developer B then branches the first archive 
to a second public archive on a second web server WB.

A can now apply changes to his own archive and merge from B's and B
can merge from A and apply his own changes to his archive. Under this
scheme he merge tree will look like this (ascii art):

   A ----+---+->
       \/  \/
       /\  /\
     ----+---+->
   B

This is the most simple example, but also works for a larger number of 
developers and developers who have private as well as public trees.

This development model is simply not available to any source control
system which can't keep track of which patches have been applied.

> Perforce (commercial) attempts to track merge history, but does a terrible
> job of it.

Perforce is just all round horrible. I use it in my day job and I'm
constantly wishing we were using Arch instead. Unfortunately we have
a number of windows users and Arch doesn't play nice with the horribly
broken windows filesystem/API/whatever.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Seen on comp.lang.python:
Q : If someone has the code in python for a buffer overflow,
    please post it.
A : Python does not support buffer overflows, sorry.