Tag: Development, Development / Home

Development

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
Home » Development

  • Forcing a commit

    5 answers - 1144 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    I've searched the archives on this, and it seems apparrent that
    Subversion has no analog for the CVS -f option to force a commit.
    development team would like to force commits for built binaries. We
    store the binaries in the subversion repository because it's a great way
    to archive our builds and distribute them to coworkers and testers.
    Maybe that's outside the scope of Subversion, but it works really well
    for our team. However, it's irritating to have to update the folders
    which store the installer images. These folders are not sotred in the
    trunk, but in a separate tree for builds, parallel to the trunk.
    The developers never care if there is a conflict, and on a slow net
    connection it is frustrating to have to perform a big worthless update
    right before a big commit.
    Even better than a -f option on commit would be a svn:ignoreconflict
    property.
    Jason Dunham
    ShotSpotter, Inc.
    To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
    For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org

  • No.1 | | 1514 bytes | |

    Jason Dunham <jdunham (AT) sfis (DOT) comwrites:
    I've searched the archives on this, and it seems apparrent that
    Subversion has no analog for the CVS -f option to force a commit.

    development team would like to force commits for built binaries.
    We store the binaries in the subversion repository because it's a
    great way to archive our builds and distribute them to coworkers and
    testers. Maybe that's outside the scope of Subversion, but it works
    really well for our team. However, it's irritating to have to update
    the folders which store the installer images. These folders are not
    sotred in the trunk, but in a separate tree for builds, parallel to
    the trunk.

    Why are you having to update the folders?

    The developers never care if there is a conflict, and on a slow net
    connection it is frustrating to have to perform a big worthless update
    right before a big commit.

    Even better than a -f option on commit would be a svn:ignoreconflict
    property.

    I think we'd want a option, and/or an
    "svn:resolution" property that says how to resolve a conflict (values
    could be 'working', 'new', 'old', etc). Thoughts?

    If I understood why you have to do that update, that'd help a lot,
    though.
    -Karl

    To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
    For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org

  • No.2 | | 3020 bytes | |

    kfogel (AT) collab (DOT) net wrote:

    >Jason Dunham <jdunham (AT) sfis (DOT) comwrites:

    >
    >>I've searched the archives on this, and it seems apparrent that
    >>Subversion has no analog for the CVS -f option to force a commit.
    >>
    >development team would like to force commits for built binaries.
    >>We store the binaries in the subversion repository because it's a
    >>great way to archive our builds and distribute them to coworkers and
    >>testers. Maybe that's outside the scope of Subversion, but it works
    >>really well for our team. However, it's irritating to have to update
    >>the folders which store the installer images. These folders are not
    >>sotred in the trunk, but in a separate tree for builds, parallel to
    >>the trunk.
    >
    >>
    >
    >Why are you having to update the folders?
    >

    There are two of us developing on the same source code in the trunk. If
    my coworker commited the last installer image, and then I make a new
    build, then I have to update to get his stale installer build before I
    can commit the current one.

    >>The developers never care if there is a conflict, and on a slow net
    >>connection it is frustrating to have to perform a big worthless update
    >>right before a big commit.
    >>
    >>Even better than a -f option on commit would be a svn:ignoreconflict
    >>property.
    >
    >>
    >
    >I think we'd want a option, and/or an
    >"svn:resolution" property that says how to resolve a conflict (values
    >could be 'working', 'new', 'old', etc). Thoughts?
    >
    >If I understood why you have to do that update, that'd help a lot,
    >though.
    >

    I like the property idea. 99% of our files work great with Subversion's
    exsisting functionality, including everything in the trunk (the source).
    But we have a whole "build" branch with about a dozen installer images,
    and I'd like to run a commit on the whole folder and have newer files
    overwrite whatever is currently in the repo. So I would set a property
    on the whole build folder so that I could force the commit on any newer
    file. course if my coworker changed one of the other images, my
    older copy should remain uncommitted. If that's hard to enforce, it
    would be fine to just run the commit on the specific subfolder with a
    flag.

    Thanks,
    Jason

    >-Karl
    >

    To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
    For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org

  • No.3 | | 1603 bytes | |

    Jason Dunham <jdunham (AT) sfis (DOT) comwrites:
    There are two of us developing on the same source code in the trunk.
    If my coworker commited the last installer image, and then I make a
    new build, then I have to update to get his stale installer build
    before I can commit the current one.

    Thanks, now I understand.

    I like the property idea. 99% of our files work great with
    Subversion's exsisting functionality, including everything in the
    trunk (the source).
    But we have a whole "build" branch with about a dozen installer
    images, and I'd like to run a commit on the whole folder and have
    newer files overwrite whatever is currently in the repo. So I would
    set a property on the whole build folder so that I could force the
    commit on any newer file. course if my coworker changed one of the
    other images, my older copy should remain uncommitted. If that's hard
    to enforce, it would be fine to just run the commit on the specific
    subfolder with a flag.

    Gosh. I'm just not sure whether the other devs would go for this, and
    I'm not sure how I feel myself.

    Would you like to post an enhancement proposal to
    dev (AT) subversion (DOT) tigris.org and see what kind of reaction you get? Use
    all the mails that have happened in this thread already, according to
    your judgement, and discard anything that seemed like a dead end.

    To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
    For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org

  • No.4 | | 2023 bytes | |

    U Nachricht
    Von: kfogel (AT) collab (DOT) net
    An: Jason Dunham <jdunham (AT) sfis (DOT) com>
    Kopie: users (AT) subversion (DOT) tigris.org, rcalhoun (AT) shotspotter (DOT) com,
    drochberg (AT) shotspotter (DOT) com
    Betreff: Re: Forcing a commit
    Datum: 23 Jun 2005 13:34:34 -0500

    Jason Dunham <jdunham (AT) sfis (DOT) comwrites:
    There are two of us developing on the same source code in the trunk.
    If my coworker commited the last installer image, and then I make a
    new build, then I have to update to get his stale installer build
    before I can commit the current one.

    Thanks, now I understand.

    I like the property idea. 99% of our files work great with
    Subversion's exsisting functionality, including everything in the
    trunk (the source).
    But we have a whole "build" branch with about a dozen installer
    images, and I'd like to run a commit on the whole folder and have
    newer files overwrite whatever is currently in the repo. So I would
    set a property on the whole build folder so that I could force the
    commit on any newer file. course if my coworker changed one of the
    other images, my older copy should remain uncommitted. If that's hard
    to enforce, it would be fine to just run the commit on the specific
    subfolder with a flag.

    Gosh. I'm just not sure whether the other devs would go for this, and
    I'm not sure how I feel myself.

    Would you like to post an enhancement proposal to
    dev (AT) subversion (DOT) tigris.org and see what kind of reaction you get? Use
    all the mails that have happened in this thread already, according to
    your judgement, and discard anything that seemed like a dead end.

    You could use svnput: it's a utility that 'puts' a file into the repository,
    overwriting what's already there. You don't even need a working copy.

    It's in the subversion repository in the tools/ or contrib/ dir.

    bye,

    Erik.

  • No.5 | | 716 bytes | |

    Erik Huelsmann wrote:

    >
    >You could use svnput: it's a utility that 'puts' a file into the repository,
    >overwriting what's already there. You don't even need a working copy.
    >
    >It's in the subversion repository in the tools/ or contrib/ dir.
    >
    >
    >bye,
    >
    >
    >Erik.
    >

    Svnput is probably good enough, but I will still write to the dev@ list
    with the feature suggestion.
    Thanks for the info.

    Jason

    To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
    For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org

Re: Forcing a commit


max 4000 letters.
Your nickname that display:
In order to stop the spam: 5 + 4 =
QUESTION ON "Development"

EMSDN.COM