For c) I assume that you mean you'd like to see *both the checkin timestamp
in addition to the last-modified timestamp. If so, I definitely agree.
I will also add mine to the list:
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.
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.
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.
I've had other thoughts, but those are what come to mind right now.
-Steve
On 1/18/07 4:33 PM, "Mike Brenner" <mikeb@mitre.org> wrote:
> Keng Lam wrote:
>> what are the things that you hate, you wish could be changed ?
>
>
> I appreciate subversion, its maintainers, this list,
> and the fact that this entire thread merely identified
> additional use cases to which subversion might
> someday expand.
>
> Three additional potentially future use cases:
>
> (a) cross-synchronizing two repositories
> e.g., one in India and one in Texxas.
>
> (b) taking a floppy home from the university
> to work on over the weekend, then
> attempting to remerge it in on Monday.
>
> (c) tracking the last-modify-date of the
> files instead of just the checked-in date.
>
> Note that all three require the same mindset-change
> to implement -- which I call a new "use case" -- a
> new way of using svn not originally designed for.
>
> Mike Brenner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
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:01:53 2007