SVN-S4

 view release on metacpan or  search on metacpan

bryce-notes.txt  view on Meta::CPAN

  "s4 up -rREV" fails
  "s4 up -r REV" is okay
- (FIXED) BUG ./update_tests.py 22 fails  (but passes without s4 wrapper)
  Unequal Types: one Node is a file, the other is a directory
  EXCEPTION: SVNTreeUnequal
  FAIL:  update_tests.py 22: update target that was added in a future rev
- (DONE) BUG: unview caused a crash, unless you later replaced the exact path with
  a new view command.  Fixed in 27071.
- (DONE) performance improvement: with viewspecs, test if a single svn update
  will suffice.  If so, it can be much faster!
  - Md5sum of the viewspec actions list, except for the revision number.
    If the md5sum matches the last completed update or checkout, and all the
    target revision numbers in the whole tree are identical, do a single update
    at the top of tree.
- (DONE) set command should set some internal hash, not the real environment variables,
  or you may be able to do nasty things
- (DONE) make this use SVN::Client: is_file_in_repo
- write regression tests for viewspec behavior
  - (DONE) checkout with viewspec
  - (DONE) update when viewspec changes
  - (DONE) test all viewspec syntax
  - you can always write more tests
- (FIXED) BUG: svn checkout -r does not obey the -r in the top level checkout
- (DONE) @list_actions should not need to be in order. just sort by target dir, and the
  order no longer matters.  Add s4_test called "s4_checkout_view2_viewlines_out_of_order"
  to regress this.
- (DONE) Undo switches when the view line is removed from viewspec.
  Store the previous parsed viewspec somewhere, and compare them so that we
  can tell what switches should be switched back.
- (DONE) document new update and checkout behavior
- (DONE) OUCH! newer svns do not allow the "switch --relocate" trick.
  So dammit I'm going to edit the .svn/entries file myself.  It's actually much easier
  than the switch relocate trick anyway.
    Make a versioned directory called A.
    Just add the line:
       <entry name="A" kind="dir"/>
    and then you can svn switch A to anything you want.
    If you don't switch it, the next update will make A get deleted.
- (DONE) BUG: "s4 --version" fails
  s4 --version   #fail
  svn --version  #ok
- (DONE) BUG: we don't allow cmdline options to appear before the svn command.
  "s4 -m message commit file" fails
  "s4 commit -m message file" ok
  "s4 commit file -m message" ok
- (DONE) when view line gives bad URL, very confusing errors result.
  Just before doing svn switch, take the time to check if it's in the repository.
- (DONE) BUG: Undoing switchpoints does the wrong thing if there are switchpoints underneath other
  switchpoints.
  mys4 up -r11; mys4 up -r12
  cd /local/denney/svn114branch/subversion/tests/clients/cmdline/working_copies/s4_tests-7.wc2
  It is ok to be over conservative (e.g. never remove any switchpoints)
  but it is not okay to make things disappear when they should not.
- (DONE) BUG: s4 does not undo void switchpoints that were created on the way to a real switchpoint.
  Really it should.
- (DONE) What happens if two view lines map the same switchpoint? Illegal, or one overrides the other?
  Now, one overrides the other.
- (DONE) if the URL is outside of the repository:
  - (DONE) test UUID
  - (DONE) print an error that it's not supported
  - or, make an svn external (svn propset . and then svn co [-r] URL PATH)
    but wait until there's a need.
- (DONE) Integrate complete_patch as "s4 snapshot"
- (DONE) Integrate strong_revert as "s4 scrub --force"



To decide:
- How to make a tag when the view is an important part of the tag?
  svn cp trunk tags/1.1
  Then you can check out the tag of trunk and you know that it's static.
  Then if you want any views to point to the tag, you svn cp the view, edit the
  Project.viewspec so that the URLs are different, and check in the view.

  trunk
  tags
    1.1
    1.2
    1.3
  views/
    viewpass1/
      Project.viewspec
    viewpep/
      Project.viewspec
  branches
    1.1.1


- s4 update simh_2006-07-01 would ideally update that directory with knowledge
  of what the viewspec says.  But in our current model, since you did not update
  from the top, the viewspec would never be considered.  That seems bad.
- what does checkout/update do with multiple arguments?  What if one of them points
  to a directory with a viewspec but others don't?
  Wilson suggests: if multiple files and one has a viewspec, crash. Force user to
  do one at a time.
- how much to display during the viewspec update?
  - (DONE) hide any implicit commits to voids area (/dev/null)
- try to use SVN::Client everywhere, or build svn commands and call system?
- (DONE) how to specify URL of voids, so that tool is not specific to our repository?
  Maybe it can find the top of repo, then add "/s4voids/NAME".
  Walk up tree, require user to create it.
- Where to store state? I thought something like $HOME/.s4/viewspec_state
  and then name file based on `/bin/pwd|md5sum` so that working areas don't get
  confused.   If it's in the working area itself, you have to change properties
  to ignore it.
  A: Use .svn/s4
- How to handle "s4 update -r 20000", when the whole view area did not exist at the time?
  One way is to use the Project.viewspec for everything.
  Another way is to somehow request that the view stay at HEAD or whatever, while
  the -r20000 affects only the switched areas. Hmm.
  A:  Have a option that doesn't update the top of the tree --noupdatetop


Testing s4:
- how to build test environment:
  wget http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.gz
  svn co svn+ssh://svn.sicortex.com/svn/master/software/devel/subversion/branches/denney_s4_tests
  cd denney_s4_tests
  ./configure LDFLAGS=-L/usr/lib64
  make
  cd subversion/tests/clients/cmdline



( run in 0.682 second using v1.01-cache-2.11-cpan-71847e10f99 )