> If we use Subversion we simply have to come to grips with a few
points:
>
> 1. If we tag liberally, we will have a very large repository directory
> (but fairly small usage of repository space).
Or you can simply refine your tagging methodology and create categories
of tags, user tagging areas, etc. The implementation is very open-ended
and flexible.
> 2. "rollback" as usually understood does not exist in Subversion. A
> similar outcome is achieved by a kind of "commit in reverse order".
> Unlike "traditional rollback", this preserves all changes (in both
> directions) in history and is slightly more complicated to execute.
Yes - removing revisions is not easy. But when you get used to it you
will probably agree that reverse-merge is really the "right" way of
doing things.
> 3. To tag individual files, we select them and copy them into a tag
> folder. Hopefully, we would not have reason to do this, because it
would
> require manual duplication of the folder tree (create folder), and I'm
not
> sure if this would be manageable or useful in the repository long
term.
Or use svn-mucc (multi url copy client) to marshal all of your mkdirs
and copyfroms into a single commit. Generally speaking, however, it is
sufficient just to tag the current state of your working copy.
> 4. We cannot look at the history of a file (in a codeline) and see
which
> labels it received, and do a compare between labels. I am unsure how
we
> could get the same result in Subversion w/o much manual work. We
would
> have to determine which tags contained the file and at what revision,
then
> initiate a comparison on the appropriate codeline based on revision
> numbers. Clunky at best, impossible at worst. In fact, this means we
> have to make sure we associate individual tags very closely to their
> branches, which I guess is a best practice anyway. If the label were
> associated with the file, rather than representing a copy of said
file,
> there would be no danger of any label being listed with the wrong
branch,
> as they are attached to the codeline in question.
You've hit the nail on the head there, with the exception of "determine
which tags contained the file and at what revision" - the url pointing
to the tagged file already implies the revision it was tagged at, just
like if you had made a physical copy of the file at that revision. The
annoying bit is the multiple svn ls queries that have to happen.
If "copyto" data was saved in the repository as well as "copyfrom" then
I think this issue would be put to rest. Seems like it kinda ties in
with merge tracking a bit, if you consider a copy merging a complete
file into an empty one :D
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 28 16:50:40 2007