On Friday 24 September 2004 10:54 am, Mark Phippard wrote:
> As for aliases, I think it is something that could be addressed once there
> is a general mechanism to push information from the server down to the
> client, such as configuration data. Once repositories have this sort of
> feature, it seems like it wouldn't be too difficult to make aliases
> something that could be configured and stored in that same area and then
> leveraged by the UI. Until then, if you really need it, you can get the
> same feature by defining and using the aliases in your shell.
I'm not sure I understand why Subversion would need a mechanism to push
information from the server to the client...
As other people have pointed out, the idea of an alias/label is to provide a
mnemonic mechanism for a referring to a specific revision number. Someone
else mentioned that Subversion already supports several special cases of this
idea: HEAD, BASE, COMMITTED and PREV are all effectively labels for a
particular global revision. Current usage:
svn co -r HEAD http://server/path localpath
Why not provide an extensible version of this, where I can say:
svn co -r MY_PRODUCT_BUILD_42 http://server/path localpath
In an earlier email, I described a situation where I used this very concept
through Perforce. It came in handy when bringing in new employees or
interns, because it saved time when setting up their workstations and made it
easier to bring them up to speed. And it REALLY came in handy when we
approached the release date, since it allowed us (developers) to more easily
isolate and fix bugs.
A typical scenario we encountered follows:
1) Install team generates Build #42 of product XYZ based on revision 1000 and
produces a label, associating XYZ_BUILD_42 with revision 1000.
2) Developers continue to make changes to the branch.
3) QA team reports a nasty, difficult bug in Build #42 that gets assigned to
me.
4) At this point, the repository is up to revision 1100. To simply my ability
to reproduce and track down the bug, I checkout XYZ_BUILD_42.
Yes, this ~can~ be accomplished using branches, but it's not exactly the same
approach. I don't need the repository to store a _copy_ of the source tree
at revision 1000. I just need to be able to easily get there, WITHOUT having
to track down the revision number. Otherwise, we have to have documentation
showing the mapping between build numbers and revision numbers.
Theoretically, one could/should use the revision number as the build number.
Unfortunately, senior management didn't like that idea: end of story.
In my mind, the two key points in the idea of supporting labels/aliases are:
1) Helps with situations where a copy of the tree is not needed or desired.
2) Helps easily identify static points in the repository that are not super
critical to long-term development.
-Sean
------------------------------
43rd Law of Computing: Anything that can go wrSegmentation fault
------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 24 22:35:17 2004