Re: RedHat 7.[23] RPMS for Subversion

> "tag" -- A pristine snapshot of prior revision(s), to which no
> changes have been made. That is, a copy, where
> nothing new has been committed to the copy's line of
> development.
>
> "merge" -- To port changes from one line of development over to
> another. For example, if you took the bugfix patch
> applied to the stable release branch, and applied that
> patch to the main development line, that would be a
> merge.

It does, thanks Karl, nice pic ;-) as did Ben's suggested

> > http://subversion.tigris.org/files/documents/15/17/svn-design.html

The concepts are now clear, but not the application - in a non-
svn-specific-ey sort of way - of the philosophy isn't ;-)

Let me make up a whole revision history here, using svn commands,
and if there are mistakes - organisational and philisophical ones
more than syntactic ones - then please let me know.

Ok, I create a 'pseudo-module' under my respository root for a project
'mumc':

        svn mkdir http://dione.no-ip.org/svn/mumc

and I provide it with the structure that was used on the svn RPMs
test site mentioned earlier today:

        svn mkdir http://dione.no-ip.org/svn/mumc/trunk
        svn mkdir http://dione.no-ip.org/svn/mumc/tags
        svn mkdir http://dione.no-ip.org/svn/mumc/branches

and then I import my work thus far into the trunk:

        cd <mumc_sources>
        svn import http://dione.no-ip.org/svn/mumc/trunk .
        cd ..

Ok, then I move <mumc_sources> out of the way and - from now on -
only work on working copies instead:

        mv <mumc_sources> <mumc_sources>.obsolete
        svn co http://dione.no-ip.org/svn/mumc/trunk -d mumc
        cd mumc

and thereafter enter a cycle of:

        vi <old_file>
        vi <new_file>
        svn add <new_file>
        svn commit -m "more feeping creaturism"

and stuff like that.

Ok, so then one day, I decide it's ready for its first release so
I ... err ... and this is where I get unsure ... edit one of the
source files so that it itself knows what release it is (for when
I type "mumc --version"), and commit this back to the trunk:

        vi patchlevel.h README NEWS <other_files_mentioning_release_id>
                (#define VERSION "1.0", etc)
        svn commit -m "bumped release id"
        
and then copy the whole of the trunk into a suitably named subdir
of tags:

        svn cp http://dione.no-ip.org/svn/mumc/trunk http://dione.no-ip.org/svn/mumc/tags/release-1.0

So then I repeat some more development loops (vi+commit) and
occassionally I make another copy into the tags subdir.

Then one day some customer with release-1.0 says they've found a
bug. So ... err ... here I can see two choices:

1) I get a working copy of release-1.0:

        svn co http://dione.no-ip.org/svn/mumc/tags/release-1.0 -d mumc

   and I'll put it back into 'branches' *after* I've fixed the bug, or

2) I clone the release into a branch first, and then get a working copy
   of the branch:

        svn cp http://dione.no-ip.org/svn/mumc/tags/release-1.0 http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001
        svn co http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001 -d mumc

Ok, so anyway, then I fix the bug:

        cd mumc
        vi buggy_file.c

And now I commit the branch back. If I made the branch according to
(2) then this is now simply:

        svn commit

but if it was according to (1) then I ... hmm ... I guess it must be
done according to (1) then, right?

Perhaps I get more bug reports here, and do the same thing making
new branches, or maybe I discover my fix for bug001 had a bug, and
that I need to do some more work on that same branch. Anyway ...

... Some time later I do a merge, to ensure that the fix for bug001
makes it into the trunk:

        svn merge http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001 http://dione.no-ip.org/svn/mumc/trunk

And finally, to indicate that that branch is now closed, that all
appropriate code from the branch has been merged into the trunk,
I delete it:

        svn rm http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001

How does that sound?

At the moment, my simple pseudo-modules all have these three 'trunk',
'tags', 'branches' subdirs (see http://dione.no-ip.org/svn), and
I don't anticipate that I'll have to deal with tagged revisions or
branching for ages, but nevertheless, I'd like to get into the right
way of thinking, so any advice, as always, would be much appreciated!

Alexis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 19 18:24:20 2002