On Jan 18, 2007, at 16:01, Steve Bakke wrote:
> 1) There have been numerous discussions on this list regarding svn-
> style
> "tags" and cvs-style tags. Reading through all of that gave me a new
> appreciation for the different usage models that people use tags
> for. The
> two main usage models I have observed are a) grouping sets of files
> into a
> release or other meaningful set. b) indicating some sort of status
> about a
> file. In general, subversion implements usage case 'a' and CVS
> implements
> usage case 'b'. Either one can be used in a way that mimicks the
> other
> use-case, but in a sub-optimal way. Why couldn't subversion implement
> support for case 'b'?
>
> 2) As a related item, could support be added to use "labels" to
> refer to
> particular revisions? This was another idea that has been discussed.
It has come up on the list many many times. I don't believe any
consensus has yet been reached on how such a feature should behave in
all cases. Is a label just an alias for a revision number? Or is it
also somehow tied to a particular repository path? How do you list
all available labels? Are labels versioned or unversioned? Different
people have in the past had different answers to these questions,
hence the current absence of the feature.
> 3) Could there be optional support for storing more information
> about a file
> lock: which machine it came from and the path for the working
> copy. This
> is useful for trying to figure out where a lock was even if you are
> the one
> who supposedly has the lock. I say to make it optional (configured
> through
> the server config) for security purposes.
Not likely. Subversion does not track who checked what out or to
where. Even if it did, anyone could just move their working copy
somewhere else, making the tracking information out of date. Anyone
can just delete a working copy they checked out; now the repository
thinks you've checked something out that you don't have anymore.
Making Subversion track who checks out and to where would be a major
change in the way Subversion works and the way people use it, which
is unlikely to gain acceptance -- what would be the benefit? If you
have so many working copies and work on so many machines that you
cannot remember where you locked a file, then just break the lock.
> 4) The way that subversion client config is handle is annoying.
> I'm in an
> environment, where the "default" configuration doesn't apply to
> everyone on
> the machine. I have a project environment where my project needs
> one set
> of defaults while another project needs something different. I
> want to be
> able to configure at the server end where the default svn config
> should be
> located. I don't know if environment variables are the answer or
> what. I
> am aware of the --config-dir option, but that isn't the solution I was
> looking for. Perhaps upon running 'svn co --config-dir' the
> working copy
> would by default continue to pick up that same config dir for
> subsequent
> commands? Obviously, wrappers are a solution, but I want something
> that
> reliably works when somebody resorts to using raw svn to get around
> inevitable limitations in any wrapper code. Having hundreds of
> users manage
> config files is a pain.
Agreed. It's unfortunate that some configs are global on the client
side, when they sometimes differ between projects or between
repositories.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 18 23:36:33 2007