I'm going to try to make a version of the svn tools that uses this
mechanism and send it around for people to try. I should be able to
do it without changing the current mechanism, so we can incrementally
try it out.
On 2007-03-21, at 14:27 EDT, Jim Grandy wrote:
Of course, an alternative to all of this would be to just adopt a
one-changeset-per-source-tree philosophy. So rather than having all
this machinery to track change subsets, we just associate a change
description with a whole local copy source tree, and always check
every change in.
Advantages:
- no need to run 'svn status' in svn-newchange
- neatly avoids the issue that 'tar' & co. don't completely capture
a Subversion change set (added files, deletes, propset, etc.)
- less bash code to maintain
Disadvantage:
- you have to make more copies of source trees in the filesystem
I've been more-or-less doing this for a few months now, and it's
pretty nice. I keep about three copies of the development tree on
my computer, and round-robin through them. One tree usually has
changes out for review, another has in-process changes, and a third
is used to review other people's change proposals.
Thoughts? Now that we have almost a year's worth of experience with
Subversion, do we really need to map in the perforce concept of
changesets anymore?
jim
On Mar 21, 2007, at 10:49 AM, Sarah Allen wrote:
oh, then updatechange would be a very nice addtion :)
On Wed, Mar 21, 2007 at 10:40 AM, P T Withington wrote:
Well, I was thinking updatechange would keep your comments and
just refresh the file list.
On 2007-03-21, at 12:55 EDT, Sarah Allen wrote:
if I'm reading this correctly, svn-update-change would be the
same as calling svn-discard-change then svn-newchange, if so I
would vote for fewer options where I can understand what each
one does. Also, can you please be consistent about the use of
dashes (svn- discardchange, rather than svn-discard-change)
Thanks,
Sarah
On Wed, Mar 21, 2007 at 9:36 AM, P T Withington wrote:
svn-newchange just creates a template and append svn status to
it (so, all the files that are modified below the current
directory).
svn-edit calls svn-newchange if no change is already in progress.
Once a change is in progress, the change text (and files listed
in it) drive the rest of the process.
So, rather than editing an existing change, if you modify more
files, you could just do svn-newchange to start over.
Which do you think is better: to add svn-update-change or svn-
discard-change, or both?
Also note svn-pending, which lists all the changes you have
started and not checked in. You can use any of those names as
an argument to the svn-* commands, so you can have multiple
changes at once if you like.
On 2007-03-21, at 09:47 EDT, Sarah Allen wrote:
I did read your previous edits to the README, which look good
overall, although I'm still unclear what svn-newchange
does.... it seems to pick up files I've modified which aren't
included in the current changeset.... where is all this magic
happening? is it keeping a list somewhere?
On Wed, Mar 21, 2007 at 5:23 AM, P T Withington wrote:
On 2007-03-21, at 01:22 EDT, Sarah Allen wrote:
On Sun, Mar 18, 2007 at 8:26 PM, P T Withington wrote:
4) svn-newchange
Not necessary if you don't have any changes yet, as 5 will
make a new change if you don't specify one.
It may be worth mentioning in the README that this step
takes many minutes on Windows when executed from $LPS_HOME.
(or is it just me?)
It does, but after that, your change is driven by the change
file, so it never has to look at your whole filesystem again.
Something that may not be obvious: Once you say new
change, it gets the modified files at that point. If you
modify more files later, you will have to manually add them
to the changeset (or discard your change and start over).
After new change, the whole process is driven by the list
of files in the change description.
How do you manually add a file to the changeset or discard
changes and start over?
What I do:
svn status
and copy the output
svn-edit
and paste the copy over the list of files that were in the
change.
Clearly this needs improvement. Probably we should provide
svn- update-change or something.
It takes it from your shell $EDITOR variable. This is part
of the revised doc I would like to check in...
I tried
%export EDITOR=vim
no luck :(
You need to ask another windows weenie how they do it.
I updated the README (and tools), with all the previous
discussion. If you update, perhaps you could review my
changes to the README? I'll add these notes today.
