[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH][RESEND] Issue #1295 (take 5)

From: Sergey <sergeyli_at_pisem.net>
Date: 2003-05-14 16:51:11 CEST

Garrett Rooney wrote:
> Honestly, I use the feature in perforce, but primarily because I can't
> figure out how to tell perforce to do a 'p4 submit foo/bar.c
> blah/baz.c'. You can do wildcards, but that only works if you want
> everything in a directory, or you can do 'everything' and edit the list,
> at least as far as I can tell. Subversion's current way of dealing with
> it seems more intuitive, the perforce way seems like a bit of a hack.

I find it a very logical feature, one that allow a coder to actually control what's being committed at a moment where this
control is needed most (let's face it, not many projects follow the tight discipline of Subversion team). Contrary to what Karl
thinks, I don't see why it would cause any damage -- losing log message sounds like more damage to me. This feature also enables
the scenario where a coder would be able to easily collect files from different directories that have changed in regards to
feature 1, and remove files that changed in regards to feature 2, which must go in a separate commit. Without such feature a
coder would rely on memory to pick files from those that have changed, which is statistically by far less reliable than that of
a PC.

BTW, in response to Garrett's question, in Perforce one can create a new [numbered] changeset and then add bunches of files to
it to form desired set of files before `p4 submit'-ting. It's not convenient though, because one needs to remember this
changeset number and type it for every "add to changeset" and for "submit" operation.

So, I'm begging to accept this feature :-). Please?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 16:52:41 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.