> "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
> "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
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
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:
svn import http://dione.no-ip.org/svn/mumc/trunk .
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
and thereafter enter a cycle of:
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
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:
And now I commit the branch back. If I made the branch according to
(2) then this is now simply:
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!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 19 18:24:20 2002