Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

On Sun, May 19, 2013 at 10:51 AM, Zé <jose.passes_at_gmx.com> wrote:
> On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
>>
>> So what's the actual problem (or problems) with SVN's branching and
>> tagging? Where does it hurt your workflow? What would make SVN not
>> "hurt you" in that way?
>>
>> Please be concrete, and give examples of what really bothers you as a
>> user or an admin in your daily work. Saying that "branches are not
>> first class", or "I don't like it that Subversion implements
>> branches/tags by copying directories" are too abstract, and really not
>> relevant. Why should I care how SVN implements its branches
>> internally, as long as it works for the use cases I need?
>
>
> This has already been repeated multiple times. Didn't you followed the
> thread?

Of course I read it, but it's very hard to find the real points buried
in the thread, in between all the abstract unsubstantiated talk.

> Again, the problem is that subversion does not support branches or tags.
> All it supports is basic file operations on a file system, and they are not
> adequate for simulating branches or tags.
>
> here's a small, concrete, reproducible example.
>
> 1) Create a brand new repository:
>
> $ svnadmin create /tmp/repository
>
>
> 2) Set the repo initial layout:
>
> $ svn mkdir branches tags trunk
>
>
> 3) Populate the trunk:
>
> $ svn checkout file:///tmp/repository working_copy
> $ cd working_copy/trunk
> $ touch main.c
> $ svn add main.c
> $ svn commit -m "Initial import"
>
>
> 4) Start a feature branch by copying the trunk directory to a dedicated
> subdirectory:
>
> $ svn copy file:///tmp/repository/trunk
> file:///tmp/repository/branches/awesome_feature
>
>
> 5) Work on the feature:
>
> $ svn checkout file:///tmp/repository/branches/awesome_feature/ feature
> $ cd feature
> $ touch good_idea_but_undoable.c
> $ svn add good_idea_but_undoable.c
> $ svn commit -m "This is a dead-end development branch, doomed to be a
> complete waste of developer's time"
>
>
> 6) Delete a development branch subdirectory:
>
> $ svn delete file:///tmp/repository/branches/awesome_feature
>
>
> 7) This is the problem:
>
> $ svn checkout --revision 3 file:///tmp/repository/branches wc
> $ cd wc && tree
>
> ze_at_ubuntu:wc$ tree
> .
> └── awesome_feature
> ├── good_idea_but_undoable.c
> └── main.c
>
> 1 directory, 2 files
>

Thanks for spelling out the single thing that bothers you in SVN's
branching implementation. Again: I don't care about the religious
point about SVN implementing its branches with (cheap) copies ...
whatever.

So you want that branches/tags are completely gone without a trace
when you're done with them? Why? To save disk space or something? To
hide secrets?

I consider this so not a problem. On the contrary, this is an
important feature of subversion: never ever lose anything that has
ever been committed (okay, there's the long-standing request for an
obliterate feature in case you really want something gone ... but
that's completely orthogonal to branches and tags).

What's the problem with awesome_feature remaining available from history?

One day, someone remembers this awesome feature that didn't work out
at the time: "Hey, do you remember how we implemented that? I'd like
to take a look at that (historic) attempt and see if we can apply it
to mega_awesome_feature."

--
Johan