Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Matthias Schniedermeyer wrote:
> On 08.09.2004 19:49, Wolfgang Fritz wrote:
> 
> 
>>Good:
>>
>>- Global version numbers. Version numbers belong to a commit, not to a file.
>>
>>Bad:
>>
>>- Branching and tagging. Conceptual, there are no branches and tags in
>>subversion. You have to emulate them by copy operations.
> 
> 
> Seems like you haven't fully(tm) understand the concept of tags &
> branches in subversion.
> 
I think I have. Each revison in subversion is basically the same what a
tag in CVS tries to achieve:a certain state (snapshot) of the repository
which you can retrieve easily. In CVS you had to create such a snapshot
by explicit tagging. So subversion is basically better. But: You have
only the numeric revisions. You can not simply give a revision which you
want to remember a mnemonic name, glue a "tag" to that revision so to
speak. Instead you have to use a bad workaround by making a copy of the
revison with a nmemonic name (and create a completely unnecessary new
revision). You even have to protect this revision explicitely against
modification (which would convert the tag to a branch).

So: internal representation: good. User interface: bad.

Branches are easy to create in subversion: Simply make a copy. But there
is no nice user interface to get the information where this branch has
its origin (even the subversion developers admit this).

Again: internal representation: good. User interface: bad.


> For braching/taging (which are the same in subversion) you create (to

Because branches and tags are technically the same in subversion, you
can modify a "tag" if you not explicitely disable it. This is stricly
against the the meaning of a tag: a snapshot of the repository. This can
be extremely dangerous if you are not careful.

> use "easy" words) a "symlink" to the revision-nr of a directory.
> 
> In CVS this would me:
> for every file create "symlink" for the relevant revision.
> This can't be "better(tm)" than what subversion does
> 
> You wouldn't need branches/tags if you could remember all the revision
> numbers (and directorys) yourself. Which would be quite possibel in
> subversion but practicaly impossibel in CVS as you would have to remeber
> the revisions of EVERY file whereas in subversion you only needed to
> rember the directory(*) and the revision-number.
> 
> 
> This is conceptionaly the best(tm) method i could think of, it is
> extremly lightweight. Whereas in CVS it is a thing that was later
> invented and the implementation is quite costly (i don't know how long
> it takes to "tag" a project like mozilla, but i doesn't want to know it
> either) and "risky" (If you interrupt the tagging/branching bad thing
> may happen to your CVS repository.) as it is NOT "conceptionaly
> integreated(tm)"
> 
> 
> 
> For "stability". I've been using subversion on my dayly job for 2 years
> now (from the changes file this was around version 0.14) and we didn't
> had any greater problem with it in 2 years. There were some smaller
> things in the beginning but what do you expect from a 0.14 version. :-)
>

It was an impression I got while reading the mailing list, but mailing
list usually are biased to negative because people who have no problems
don't write to the list. We will use subversion in the company for all
new projects and I'm quite sure we will not have major problems.

> (e.g. as the versions came out we had to "dump" and recreate the
> repository about 3 or 4 times. But currently the binary-format is
> declared stable and only a "2.0"-version may(/will) break the current
> binary format)
> 
> 
> 
> 
> *: In subversion the whole repository is versioned.
> 
> The directorys branches/<...> tags/<...> trunk (the "head" version) are
> pure convention and you can/could use whatever names you like.
> You may even put many software projects into the same repository if you
> like that better.
> 
> 
> Bis denn
> 






Home | Main Index | Thread Index