Hm, those are very good points, Karl.
I was originally going to reply that you and CMike were both sort of
throwing shadows, giving fuzzy arguments that "in your gut" this
implementation wouldn't lead us down the path we wanted. My reply
would have been along the lines of quoting ghudson ("don't let the
perfect become the enemy of the good").
But you're right, using scattered entries files as a database is a
pretty poor design. And yeah, it makes it hard to implement
overlapping changesets. I probably wasn't noticing this problem
because all of the subcommands that filter on the new label are doing
recursive walks anyway... but there are many other uses for
changelists, and a client application shouldn't *have* to do a
recursive walk just to know who a changelist's members are. Yuck.
That's really restrictive.
So, I concede. I just wish that, you know, somebody had been paying
attention to my commits all last May. A simple "don't do it that way"
would have saved a lot of time and backtracking. :-) Back then, we
spent a long while hashing out the use-cases and UI (in
notes/changelist-design.txt), but no time discussing underlying
implementation. Seems like the design file is still good, but the
implementation is not.
* Should I start by reverting my 3 or 4 revisions?
* Is anyone interested in coming up with a better implementation in
the commandline client? Working with me?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 04:47:08 2007