Properties get inherited from one revision of a file to the next, correct?
The equivalent of a CVS-style tag would be a property that is specific to
one revision of a file. That's why the implementation was slow in CVS.
On 1/18/07 6:57 PM, "Miller, Eric" <Eric.Miller@amd.com> wrote:
> WRT point 1. wouldn't propsets account for your case B use model?
>
> 2 sounds suspiciously like blasphemy.
It's probably not useful enough to be worth implementing, but I thought it
was an interesting idea. Effectively a name would be a synonym for a
revision number.
>
> I really like 3.
>
> I like 4. svn co --config-dir should set the default config for the
> working copy.
>
> I also like the upcoming feature (that they are discussing scrapping in
> dev) of changesets. Good for code development,
Somehow I hadn't heard about this one. What exactly was being proposed?
Why are they considering scrapping it?
-steve
>
> Eric
>
>> -----Original Message-----
>> From: Steve Bakke [mailto:steven.bakke@amd.com]
>> Sent: Thursday, January 18, 2007 3:01 PM
>> To: users@subversion.tigris.org
>> Subject: Re: What do you Hate about Subversion?
>>
>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 19 04:31:20 2007